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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

(g) Verfahren und Vorrichtungen zum Zugrelfen auf Nachrlchten 

(57) Es wird ein Verfahren vorgestellt, das es ermoglicht, 
eine vorzugsweise uber ein Mobilfunksystem und/oder 
das Internet versendete erste Nachrlchten, Insbesondere 
einer multlmedialen Nachricht, vorzugsweise vom MMS- 
Typ, mittels einer nach der ersten Nachricht versendeten 
zweiten Nachricht zu manipulieren, beispielsweise zu- 
ruckzurufen oder zu andern. Gleichfalls wird eine Sende- 
und/oder Empfangseinheit mit Mittein zum Erstellen, Ver- 
senden, Empfangen und/oder Verarbeiten einer ersten 
N ach rich t off enbart, welche Mittel zum Einstellen, Versen- 
den, Empfangen und/oder Verarbeiten einer zweiten 
Nachricht mit einem Manipulationsauftrag zum Manipu- 
lieren der zuvor gesendeten ersten Nachricht umfafSt. Zu- 
dem wird ein Kommunikationssystem mit mindestens ei- 
nem Netzwerkelement beschrieben, welches Mittel zum 
Empfangen, Verarbeiten und/oder Weiterleiten einer 
zweiten Nachricht mit einem Manipulationsauftrag um- 
faBt, welcher sich auf eine empfangene und ggf. schon 
weitergeleitete erste Nachricht bezieht, um einen mani- 
pulierenden Zugriff auf die erste Nachricht zu veranlassen 
oderzu vermitteln. 
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Beschreibung 

[0001] Die Erfindung betrifft ein Verfaliren zum Zugreifen auf eine erste Nachricht, insbesondere eine multimediale 
Nachricht vorzugsweise vom MMS-Typ, wobei die erste Nachricht mittels einer Sendeapplikation einer Sendeeinheit an 
5 eine Empfangsapplikation einer Empfangseinheit gesendet wird. 

[0002] Des weiteren betrifft die Erfindung eine Sende- und/oder Empfangseinheit mit Mitteln zum Erstellen, Versen- 
den, Empfangen und/oder Verarbeiten einer ersten Nachricht, insbesondere einer multimedialen Nachricht vorzugsweise 
vom MMS-Typ. 

[0003] Zudem betrifft die Erfindung ein Kommunikations system, insbesondere Funkkommunikationssystem, mit mit 

10 Sende- und/oder Empfangseinheiten kommunizierfahigen Netzwerkelementen, welche Mittel zum Empfangen und Wei- 
terleiten von Nachrichten, insbesondere multimedialen Nachrichten vorzugsweise vom MMS-Typ, umfassen. 
[0004] Das Mobilfunksystem GSM (GSM - Global System for Mobile Communications) bietet neben der Sprachtele- 
fonie auch die Moglichkeit, kurze Textnachrichten von bis zu 160 Zeichen Lange zu versenden bzw. zu empfangen. Die- 
ser Dienst heiBt SMS (SMS - Short Message Service), s. GSM 03.40 version 7.4.0, Release 1998; Digital Cellular Tele- 

15 conmiunications System; Technical Realisation of the Short Message Service (SMS). 

[0005] Fiir das Mobilfunksystem der nachsten Generation UMTS (UMTS - Universal Mobile Telecommunication Sy- 
stem) wird zur Zeit eine multimediafahige Variante eines mobilen Nachrichtendienstes standardisiert, der sogenannte 
MMS (MMS - Multimedia Messaging Service), s. 3G TS 22. 140 version 4.0. 1 , Release 2000; Third Generation Partner- 
ship Project; Technical Specification Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messa- 

20 ging Service (MMS). Nachrichten mit multimedialen Inhalten werden im folgenden zur besseren Abgrenzung von den 
Textnachrichten des SMS nur noch kurz MMs (MM - Multimedia Message; Plural: MMs) genannt. Im Gegensatz zum 
SMS entfallt die Beschrankung auf reine Textinhalte. Beim MMS wird es moglich sein, Texte dem individuellen Ge- 
schmack entsprechend zu formatieren sowie Audio- und ^^deoinhalte in eine Nachricht einzubetten. Eine weitere Neuig- 
keit ist, dal3 bei der Zustellung von MMs bekanntermaBen zwischen dem sogenannten PUSH-Modus (Druck-/Bring-Mo- 

25 dus), bei dem eine ankommende mm unverzuglich dem Empfanger zugestellt wird, und dem sogenannten PULL-Modus 
(Zieh-/Hol-Modus), bei dem der Empfanger zunachst iiber eine neu eingetroflfene mm informiert wird und daraufhin 
selbst entscheiden kann, wann er diese mm auf sein Endgerat herunterladt, unterschieden wird. Diese bekannten Zusam- 
menhange sind in Fig. 1 verdeutlicht. 

[0006] Nach dem bisherigen Stand der Technik ist eine Implementierung von MMS lediglich iiber WAP (WAP - Wi- 
30 reless Application Protocol) realisierbar. Zur Uberbriickung der Luftschnittstelle zwischen einem MMS-taugHchen End- 
gerat und dem WAP Gateway ist die Benutzung des WAP WSP (WSP - Wireless Session Protocol), s. WAP-203-WSP, 
Version 4-May-2000; Wireless Application Protocol, Wireless vSession TVotocol vSpecification; Chapter 8.4: "TTeader En- 
coding", vorgesehen, s. 3GTS 22.140 version 4.0.1, Release 2000, Third Generation Partnership Project, Technical Spe- 
cification Group Services and System Aspects, Service Aspects, Stage 1, Multimedia Messaging Service (MMS); 3G TS 
35 23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Terminals, Multi- 
media Messaging Service (MMS), Functional Description, Stage 2. 

[0007] Fig. 2 zeigt ein sogenanntes Transaktions-FluB-(Transaction Flow)Diagramm nach heutigem Stand der Technik 
gemaB 3G TS 23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Ter- 
minals, Multimedia Messaging Service (MMS), Functional Description, Stage 2, in dem der Austausch der WAP Nach- 

40 richten zwischen den drei beteiligten Instanzen (MMS User Agent A, MMS Relay und MMS User Agent B) beim Ver- 
sand und Empfang einer MM dargestellt ist. Unter MMS User Agent versteht man eine Applikation auf einem Mobil- 
funkgerat oder auf einem an ein Mobilfunkgerat angeschlossenen Gerat (z. B. Laptop, o. a.), die MMS realisiert. Ein 
MMS Relay ist ein Netzwerkelement im Zustandigkeitsbereich des MMS Service Providers, das den MMS User Agents 
die MMS-Funktionalitat zur Verfiigung stellt. 

45 [0008] Im folgenden wird anhand des bekannten Transaktions-FluB-Diagramms in Fig. 2 ("User Agent A schickt 
MMa an User Agent B") der Austausch der WAP Nachrichten beschrieben. Dabei wird zunachst vereinfachend davon 
ausgegangen, daB MMS User Agent A und MMS User Agent B den MMS vom gleichen MMS Service Provider in An- 
spruch nehmen: Die im MMS User Agent A erzeugte MMa wird mit der WAP Nachricht M-Send.req an das MMS Relay 
geschickt. Daraufhin erhalt das MMS User Agent A die WAP Nachricht M-Send.conf zuruck, mit der der korrekte Emp- 

50 fang der MMa vom MMS Relay bestatigt wird. In ihr ist auch eine vom MMS Relay festgelegte, moglicherweise indi- 
viduelle, Identifikationsnummer IDl fur die abgeschickte MMa enthalten. Danach informiert das MMS Relay das MMS 
User Agent B mit der WAP Nachricht M-Notification.ind iiber den Speicherplatz (URI - Uniform Resource Identifier) 
der neu eingetroffenen und zum Herunterladen (Download) bereitliegenden MMa. Das MMS Relay erhalt daraufhin 
z. B. mit der WAP Nachricht M-NotifyResp.req eine Bestatigung, daB die Benachrichtigung uber die eingen*oftene MMa 

55 (M-Notification.ind) erfolgreich zugestellt worden ist. Zu diesem Zeitpunkt hat das MMS Relay noch keine Nachrichten- 
ID fiir die zum Herunterladen bereitliegende mm vergeben. Beim Austausch der beiden WAP Nachrichten M-Notificati- 
on.ind und M-NotifyResp.req wird nur eine fiir diese Benachrichtigung individuelle TVansaktions-Identitatsnummer 
(Transaction-ID) ausgetauscht. Das MMS User Agent B fordert dann mit Hilfe der WAP Nachricht WSP GET, mit der 
der URI an das MMS Relay geschickt wird, die Auslieferung der MMa an. Mit der WAP Nachricht M-Retrieve.conf 

60 wird dem MMS User Agent B daraufhin vom MMS Relay die gewiinschte MMa zugestellt. Hierbei wird die MMa iiber 
die vom MMS Relay vergebene, moglicherweise individuelle, Identifikationsnummer ID2 identifiziert. Mit der WAP 
Nachricht M-Acknowledge.ind wird der korrekte Empfang der MMa vom MMS User Agent B quittiert. Fiir den Fall, 
daB der Absender den Wunsch geauBert hat, iiber einen erfolgreichen Empfang der von ihm verschickten MMa benach- 
richtigt zu werden, kann das MMS Relay dem nachkommen, indem die WAP Nachricht M-Delivery.ind an das MMS 

65 User Agent A geschickt wird. 

[0009] Fig. 3 zeigt eine bekannte mogliche MMS Architektur, bei der die beiden am Austausch einer mm beteiligten 
MMS User Agents (MMS User Agent A mit Bezugszeichen 1 und MMS User Agent B mit Bezugszeichen 11) den MMS 
von verschiedenen MMS Service Providem (MMS Service Provider A und MMS Service Provider B) in Anspmch neh- 
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men. In diesem Fall ist eine Weiterleitung der mm zwischen den MMSEs (MMSE - Multimedia Messaging Service En- 
vironment) der beteiligten MMS Service Provider notig. Das Bezugszeichen 4 kennzeichnet die MMSE des Service Pro- 
viders A und das Bezugszeichen 14 die MMSE des Service Providers B. Die Weiterleitung einer mm zwischen zwei 
MMSEs und hierbei genauer zwischen der Sendeapplikation MMS Relay A mit Bezugszeichen 2 und der Empfangsapp- 
likation MMS Relay B mit Bezugszeichen 12) geschieht uber SMTP (SMTP - Simple Mail Transfer Protocol), s. 3G TS 5 
23.140 version 4.0.0, Release 4, Third Generation Partnership Project, Technical Specification Group Terminals, Multi- 
media Messaging Service (MMS) Functional Description, Stage 2, z. B. durch das Internet (TP - Internet Protocol mit 
Bezugszeichen 20). Das ProtokoU SMTP ist in Fig. 3 mit dem Bezugszeichen 22 bezeichnet. Das Mobilfunknetz wird in 
Fig. 3 wie allgemein iiblich als PLMN (PLMN - Public Land Mobile Network) bezeichnet und tragi in Fig. 3 das Be- 
zugszeichen 6. Jeder MM kann beim Editieren ein Zeitpunkt zugewiesen werden, zu dem die MM friihestens dem Emp- 10 
fanger, dem MMS User Agent B mit Bezugszeichen 11, zugestellt werden soil. Wird davon Gebrauch gemacht, ist eine 
Zwischenspeicherung der MM im MMSEa 4 (genauer: einem Speicher MMS Server A mit Bezugszeichen 3) des Ab- 
senders (MMS User Agent A) 1 bis zum Erreichen dieser Frist vorgesehen, s. Report of the 3(tPP TS(t-T2 SW(t3 MMS 
Ad Hoc Meeting #5 in Sophia AntipoUs, France 10-12 October 2000; T-doc: T2M00092; chapter 7; 3GPP TSG-T2 
SWG3. Erst danach wird die MM an das MMSEb 14 des Empf angers (MMS User Agent B) 11 tibermittelt. Weiterhin 15 
kann beim Editieren einer jeden mm auch eine gewiinschte Gultigkeitsdauer angegeben werden. Die Speicherung einer 
mm bis zum Ablauf der Giiltigkeit bzw. bis zum vorherigen Download der MM durch den MMS User Agent B 11 soil im 
MMSEg 14 (genauer: in einem Speicher MMS Server B mit Bezugszeichen 13) des Empfangers 11 stattfinden, s. Report 
of the 3GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in Sophia Antipohs, France 10-12 October 2000; T-doc: 
T2M00092; chapter 7; 3GPP TSG-T2 SWG3. 20 
[0010] Bei den eingangs genannten Verfahren und Vorrichtungen ist eine Nachricht vom Absender bzw. Auftraggeber 
bearbeitbar, solange sie sich noch in der Sendeapplikation MMS User Agent A befindet. Wenn die Nachricht abgesandt 
wurde, besteht keine MogHchkeit der Beeinflussung bzw. des Zugreifens mehr. Dieses Problem besteht nicht nur bei der 
Versendung von Nachrichten iiber Funk, sondem auch bei der Versendung von elektronischer Post (Emails) iiber das In- 
ternet und anderen Nachrichten-Systemen. 25 
[0011] Es ist Aufgabe der vorliegenden Erfindung, das Verfahren und die Vorrichtungen der eingangs genannten Art 
derart weiterzubilden, dal3 eine mehr den Bedurfnissen des Absenders/Empfangers orientiertere Bearbeitung bzw. Beein- 
flussung von Nachrichten ermoglicht wird. 

[0012] Diese Aufgabe wird bei dem Verfahren der eingangs genannten Art dadurch gelost, daB eine zweite Nachricht 
mit einem Manipulationsauftrag zur Manipulation der ersten Nachricht erstellt, versendet, empfangen, weitergeleitet 30 
und/oder verarbeitet wird, um einen manipulierenden Zugriif auf die erste Nachricht zu veranlassen oder zu vermitteln. 
[0013] Weiterhin wird diese Aufgabe bei einer Sende- und/oder Empfangseinheit der eingangs genannten Art gelost 
Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer zweiten Nachricht, wobei die zweite Nachricht 
einen Manipulationsauftrag zum Manipulieren einer zuvor gesendeten ersten Nachricht umfaBt. Unter dem Begrilf 
Sende- und/oder Empfangseinheit werden insbesondere Mobilfunktelefone sowie mit dem Internet verbundene Kommu- 35 
nikationseinheiten einschlieBlich Computer verstanden. Die erfindungsgemaBen Mittel zum Erstellen, Versenden, Emp- 
fangen und/oder Verarbeiten der zweiten Nachricht umfassen - neben den geratetechnischen Voraussetzungen — insbe- 
sondere Softwarelosungen, die nachfolgend genauer vorgestellt werden und bevorzugt Modifikationen von WAP-Nach- 
richten mit veranderten und/oder neu definierten Kopffeldem darstellen bzw. diese verarbeiten konnen. 
[0014] Zudem wird diese Aufgabe bei einem Kommunikationssystem der eingangs genannten Art dadurch gelost, daB 40 
mindestens eines der Netzwerkelemente Mittel zum Empfangen, Verarbeiten und/oder Weiterleiten einer zweiten Nach- 
richt mit einem Manipulationsauftrag umfaBt, welcher sich auf eine empfangene und ggf schon weiteigeleitete erste 
Nachricht bezieht, um einen manipulierenden Zugriff auf die erste Nachricht zu veranlassen oder zu vermitteln. Im Sinne 
dieser Erfindung wird unter einem Kommunikationssystem ein System mit Netzwerkelementen verstanden, die eine 
Kommunikation zwischen melireren Sende- und/oder Empfangseinheiten, insbesondere mehreren Mobiltelefonen und/ 45 
oder ans Internet angeschlossenen Rechnern, ermoglichen. Das Kommunikationssystem einschlieBlich Funkkommuni- 
kationssysteme wird iiblicherweise von Service Providem betrieben. Die erfindungsgemaBen Mittel zum Empfangen, 
Verarbeiten und/oder Weiterleiten der zweiten Nachricht schlieBen auBen den notwendigen Hardware-Elementen insbe- 
sondere Sofware ein, die im folgenden genauer beschrieben wird und bevorzugt Modifikationen von "WAP-Nachrichten 
mit ensprechend angepafSten oder neu definierten Kopfl:eldem darstellen bzw. diese verarbeiten konnen. 50 
[0015] Eine Nachricht im Sinne dieser Erfindung kann sowohl eine herkommliche SMS, eine MM mit multimedialen 
Inhalten oder eine sonstige elektronische Nachricht sein. Im folgenden wird die Erfindung anhand der MM beschrieben, 
ohne daB hierdurch eine Einschrankung auf diesen Nachrichtentyp erfolgen soil. Fiir die erste Nachricht wird im folgen- 
den die Abklirzung MMa, fiir die zweite Nachricht die Abkiirzung MM^^ verwendet. 

[0016] Die Vorteile der Erfindung liegen insbesondere darin, daB es ermoglicht wird, eine erste Nachricht nach dem 55 
Abschicken zu manipulieren, insbesondere zuriickzurufen und/oder nachtraglich eine Veranderung bzw. Aktualisierung 
an ihr vorzunehmen. Eine solche Manipulation kann gemaB der Erfindung bei der Versendung von Nachrichten iiber 
Funk, fiber Mobilfiinksysteme, zwischen Mobilfunksystemen, insbesondere fiber ein Inter-Operator-IP-backbone, zwi- 
schen Mobilfunknetzen und anderen Nachrichten-Systemen, insbesondere Internet-Email, und/oder fiber das Internet 
moglich sein. 60 
[0017] Insbesondere ist es mit Hilfe der vorliegenden Erfindung moglich, eine von einem Auftraggeber mittels einer 
Sendeapplikation einer Sendeeinheit fiber mindestens ein Netzwerkelement an eine Empfangsapplikation einer Emp- 
fangseinheit gesendete erste Nachricht - insbesondere eine Multimedia Message nach dem MMS-Typ - zu manipulieren, 
wobei nach Versenden der ersten Nachricht eine zweite Nachricht mit einer ManipuHerinformation von der Sendeeinheit 
an mindestens ein Netzwerkelement ubermitteit wird, das einen manipulierenden Zugriff auf die erste Nachricht veran- 65 
laBt oder vermittelt. 

[0018] Die erste Nachricht und die zweite Nachricht werden fiber mindestens ein senderseitiges Netzwerkelement ei- 
nes Service Providers und mindestens ein empfangerseitiges Netzwerkelement eines Service Providers an die Empfangs- 
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applikation gesendet. Hierbei konnen das mindestens eine senderseitige Netzwerkelement und das mindestens eine emp- 
f anger seitige Netzwerkelement dem Zustandigkeitsbereich eines einzigen Service Providers angehoren oder sogar - im 
einfachsten Fall identisch sind. 

[0019] Audi sind Falle einer Identitat der Empfangs- und der Sendeapplikation moglich. 
5 [0020] Besonders bevorzugt erfolgt der manipulierende Zugriff auf die erste Nachricht auf einem senderseitigen Netz- 
werkelement, auf einem empfangerseitigen Netzwerkelement und/oder auf der Empfangsapplikation. 
[0021] 1st die Empfangsapplikation noch nicht iiber den Manipulationsauftrag informiert worden, wird die erste Nach- 
richt bevorzugt entweder im Zustandigkeitsbereich des senderseitigen oder des empfangerseitigen Service Providers ma- 
nipuliert, vorzugsweise ohne die Empfangsapplikation iiber die Manipulation zu benachrichtigen. 1st die Benachrichti- 
10 gung uber die erste Nachricht schon an die Empfangsseite hingegen erfolgt, aber ist diese erste Nachricht noch nicht her- 
untergeladen, wird vorzugsweise die erste Nachricht im Zustandigkeitsbereich des senderseitigen Service Providers ohne 
Informieren der Empfangsapphkation manipuliert, oder die Manipulation erfolgt im Zustandigkeitsbereich des empfan- 
gerseitigen Service Providers, wobei bevorzugt die Empfangsapplikation iiber die Manipulation und deren Zeitpunkt in- 
formiert wird. 

15 [0022] Die erfindungsgemaBe Manipulation ist nicht auf die beiden Dienstmerkmale Zuriickrufen und Andern be- 
schrankt. Auch Auftrage zu einer nachtraglichen Weiterleitung (Forwarding), ein nachtragliches Anhangen der zweiten 
Nachricht an die erste Nachricht, usw. wird im Sinne dieser Erfindung unter einer Manipulation verstanden. Im folgen- 
den werden der Riickruf- und der Anderungs-Auftrag genauer beschrieben. 

[0023] GemaB der Erfindung kann das Zuriickrufen (im Rahmen dieser Offenbarung mit "Recall" bezeichnet) einer 
20 MM zumindest immer noch solange moglich sein, bis sie der Empfanger in einen anderen Ordner verschoben, an einen 
anderen Empfanger weitergeleitet oder geoffnet hat. 

[0024] Das nachtragliche Andern (im Rahmen dieser Offenbarung mit "Replace" bezeichnet) einer MM hingegen ist 
vorteilhafterweise auch dann noch moglich, wenn der Empfanger die MM schon "angefafit" hat. In diesemFall wird der 
Empfanger vorzugsweise umgehend iiber eine nachtragliche Anderung der entsprechenden M informiert, entweder 

25 durch eine Benachrichtigung (Notification), damit er den Download der aktualisierten mm nachtraglich selbst einleiten 
kann (Pull- Modus), oder gleich durch eine automatische Zustellung der aktualisierten mm (Push-Modus). 
[0025] Des weiteren ist Gegenstand der Erfindung die Implementierung des erfindungsgemaBen Verfahrens in WAP 
durch die Modifikation von vorhandenen Header-Feldern oder das Hinzufiigen von neu definierten Header-Feldern in die 
betroffenen WAP Nachrichten des WAP-MMSEncapsulation Standards, s. WAP-209-MMSEncapsulation, Release 

30 2000; Wireless Application Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed 
SCD 1.0. 

[0026] Ebenso ist das entsprechende binare Encoding, wie weiter unten fiir ein Ausfuhrungsbei spiel beschrieben, Ge- 
genstand der vorliegenden Erfindung. 

[0027] Im folgenden wird die Erfindung anhand von Beispielen naher erlautert. 
35 [0028] Es zeigen: 

[0029] Fig, 1 eine Gegeniiberstellung des PULL- und PUSH-Modus gemaB UMTS nach dem Stand der Technik; 
[0030] Fig, 2 ein Multimedia Messaging Service (MMS) Transaktions-Diagramm nach dem Stand der Technik; 
[0031] Fig, 3 eine schematische Darstellung einer Multimedia Messaging Architektur nach dem Stand der Technik; 
[0032] Fig, 4 ein Multimedia Messaging Service (MMS) mit einer Manipulationsmoglichkeit einer ersten Nachricht 

40 gemaB der vorliegenden Erfindung; 

[0033] Fig, 5 eine Codierung von neu definierten Kopflfeldem (Header-Felder); 
[0034] Fig, 6 Erganzungen im bekannten Kopffeld X-Mms-Status; 
[0035] Fig, 7 neu eingefiihrtes Kopffeld X-Mms- Original- Mess age-Status; und 
[0036] Fig, 8 neu eingefiihrtes Kopffeld X-Mms-Original- Message-ID. 

45 [0037] Es wird - unter Bezugnahme auf das obere Drittel der Fig, 4 — bei der Beschreibung der Ausfiihrungsbeispiele 
von dem folgenden, bekannten Ablauf des Versendens und Empfangens einer ersten Nachricht MMa durch Vermittlung 
eines ersten und eines zweiten Service Providers (Service Provider A und Service Provider B) ausgegangen: Nach dem 
Verschicken der ersten Nachricht MM^ wird der Sendeapplikation MMS User Agent A des Absenders in der WAP Nach- 
richt M-send.conf eine Message-ID fiir die zuvor verschickte MMa mitgeteilt (IDl). Diese Identifikationsnummer IDl 

50 wird vom Netzwerkelement MMS Relay A des Service Providers A erzeugt und kennzeichnet die MMa innerhalb der 
senderseitigen Schnittstelle MMS User Agent A/MMS Relay A eindeutig. Bei der empfangerseitigen Zustellung der 
MMa vom Netzwerkelement MMS Relay B des Service Providers B zur Empfangsapplikation MMS User Agent B 
durch die WAP Nachricht M-Retrieve.conf wird ebenfalls eine Message-ID (ID2 in Fig, 2) iibermittelt. Diese Identifika- 
tionsnummer ID2 wird moglicherweise vom MMS Relay B neu erzeugt und dient zur eindeutigen empfangerseitigen 

55 Kennzeichnung der MMa innerhalb der Schnittstelle MMS Relay B/MMS User Agent B. 

[0038] Zur Ubermittlung der MMa zwischen dem senderseitigen MMS Relay A und dem empfangerseitigen MMS Re- 
lay B kann IDl in eine Interim-Identifikationsnunmier (ID3) umgewandelt werden, welche die MMa zwischen den ver- 
schiedenen Systemen identifiziert. Insbesondere soUte ID3 global eindeutig sein. Z. B. enthalt ID3 Informationen hin- 
sichtlich des Service Providers A, der IDl sowie dem Zeitpunkt der ID-Umwandlung. Dazu muB das senderseitige NIMS 

60 Relay A die Information bzw. die Moglichkeit besitzen, diese Umwandlung wieder riickgangig zu machen, z. B. fiir Aus- 
lieferungsberichte. Um intern iibersichtliche IDs zu benutzen, kann ID3 vom empfangerseitigen MMS Relay B in die 
oben erwahnte interne ID2 umgewandelt werden, welche die MMa zum Empfanger MMS User Agent B identifiziert. 
Dazu mu6 wiederum das emp^ngerseitige MMS Relay B die Information bzw. die Moglichkeit besitzen, diese Um- 
wandlung wieder riickgangig zu machen, z. B. fiir Ausheferungsberichte. Die MMa wird empfangerseitig durch ID2 

65 identifiziert. 

[0039] (lemaB der Erfindung wird nun von der Sendeapplikation, der Empfangsapplikation und/oder zwischen der 
Sende- und Empfangsapplikation vermittelnden Netzwerkelementen die Moglichkeit zum Zugriff auf die zuvor versen- 
dete erste Nachricht MMa bereitgestellt, indem eine zweite Nachricht MMb bereitgestellt wird, die einen manipulieren- 
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den Zugriff auf die erste Nachricht MM^ veranlaBt oder vemiittelt. 

[0040] Eine Moglichkeit der Identifikation von MMb wird folgend anhand der Fig. 4 erlautert, bei der MMb die Iden- 
tifikationsnummer ID4 tragi. Zur Ubemiittlung von MMg zwischen den verschiedenen Service Providem Systemen kann 
rD4 vom senders eitigen MMS Relay A umgewandelt werden in eine Interim-ID (ID6), welche MMb zwischen den Sy- 
stemen identifiziert. Insbesondere soUte ID6 global eindeutig sein, z. B. eine Kombination von Informationen hinsicht- 5 
lich des Service Providers A, ID4 und Zeitpunkt der Umwandlung enthalten. Dazu muB das senderseitige MMS Relay A 
die Information bzw. die Moglichkeit besitzen, diese Umwandlung wieder riickgangig zu machen, z. B. fiir Ausliefe- 
rungsberichte. Um intern iibersichtlichere IDs zu benutzen, kann ID6 vom empf angerseitigen MMS Relay B umgewan- 
delt werden in eine interne ID (IDS), welche MMb zum Empfanger MMS User Agent B identifiziert. Dazu niuB das emp- 
fangerseitige MMS Relay B die Information bzw. die Moglichkeit besitzen, diese Umwandlung wieder riickgangig zu 10 
machen, z. B. fur Auslieferungsberichte. MM^ wird empfangerseitig durch IDS identifiziert. 

[0041 J Um die notwendige Verbindung von MMa und MMb zu realisieren, weist ID4 eine Referenz zu ID 1, ID6 eine 
Referenz zu ID3 und EDS eine Referenz zu ID2 auf. Die Benachrichtigungen der Empf angsapplikation MMS User Agent 
B iiber MMa und MM^ verweisen zudem auf zwei Speicherplatze URIl bzw. URI2. 

[0042] Es ist moglich, daB die Identifikationsnummem IDl und ID3, ID3 und ID2, sowie IDl, ID2 und ID3 identisch 15 
sind. Ebenso konnen ID4 und ID6, ID6 und IDS, sowie ID4, IDS und ID6 identisch sein. 

[0043] Zumindest eines der beteiligten senderseitigen und eines der beteiligten empfangerseitigen Netzwerkelemente 
ist vorteilhafterweise in der Lage, eine eindeutige, umkehrbare Umwandlung von IDs vorzunehmen und die Informatio- 
nen hieriiber zu verwalten. 

[0044] Im folgenden werden die Manipulationsmoglichkeiten "Riickruf ' und "Andem" beispielhaft beschrieben, wor- 20 
unter unter dem letzteren Begriff im Sinne dieser Erfindung beispielsweise eine Aktualisierung der ersten Nachricht 
MMa verstanden wird, insbesondere durch Ersetzen der ersten Nachricht durch die zweite Nachricht. Allgemein sind je- 
doch alle Kombinationen der gemaB dieser Erfindung offenbarten Optionen fiir alle Arten von Manipulationen realisier- 
bar, so z. B. ob und mit welchen Informationen der Empfanger iiber eine Manipulation einer ersten Nachricht benach- 
richtigt wird, ob iiber die Art der Manipulation informiert werden soil, ob der Empfanger iiber einen Manipulations- 25 
wunsch des Absenders informiert werden soil, ob die zweite Nachricht im PULL- oder im PUSH-Modus zugesteILt wer- 
den soil, ob die Anderung auf einem senderseitigen oder empfangerseitigen Netzwerkelement oder auf der Empf angs- 
applikation MMS User Agent B erfolgen soil, ob der Ab sender und/oder der Empfanger iiber den Erfolg der Manipula- 
tion benachrichtigt werden soil, usw. 

30 

A. Riickruf-Dienstmerkmal 

[0045] GemaB der Erfindung kann ein Benutzer des MMS, der eine erste Multimedia Message MMa abgeschickt hat 
und diese bereits verschickte MMa wieder zuriickrufen mochte, eine neue, zweite Nachricht MMb mit der Information 
verschicken, daB die zuvor verschickte, erste Nachricht MMa wieder zuriickgerufen werden soil. 35 
[0046] Dies kann erfindungsgemaB bevorzugt dadurch realisiert werden, indem der Absender die neue MMb verfaBt, 
die einen Riickruf-Befehl, aber bevorzugt keinen fiir den Empfanger bestimmten Inhalt (Content/Message Body), bein- 
haltet, und diese an den gleichen Empfanger wie die zuvor verschickte MMa schickt. AIs Ruckruf-Kennung wird bevor- 
zugt die IDl der zuvor verschickten MMa benutzt. Die MMb niit der Riickmf-Information gelangt zunachst zum MMS 
Relay A des Absenders. Hier wird zweckmaBigerweise iiberpriift, ob die MMa mit der IDl noch im Zustandigkeitsbe- 40 
reich des Service Providers A (MMSEa) ist, oder ob sie schon an das MMSEb des Service Providers B weitergeleitet 
worden ist. Ers teres ist z. B. der Fall, wenn der vom Absender gewahlte Zeitpunkt fur die gewiinschte Zustellung seiner 
MMa noch nicht erreicht worden ist; letzteres ist z. B. der Fall, wenn die MMa noch nicht ihre Giiltigkeitsdauer iiber- 
schritten hat und noch nicht dem MMS User Agent B zugestellt worden ist. Sobald die MMa in einem MMSE der betei- 
ligten MMS Service Provider ausfindig gemacht wird, kann das Loschen von MMa und MMb vom zustandigen MMS 45 
Relay eingeleitet werden. 

[0047] Falls das MMS User Agent B schon iiber die fiir ihn im MMSEb bereitliegenden MMa mittels einer Benach- 
richtigung (Notification) informiert worden ist und sich die MMa noch im Zustandigkeitsbereich/Speicher des Service 
Providers B befinden soUte, kann nach dieser Erfindung das MMS User Agent B mit einer emeuten Benachrichtigung 
(Notification) davon in Kenntnis gesetzt werden, daJ3 die MMa vom Service Provider B geloscht worden ist und somit 50 
nicht mehr zum Download bereit liegt, weil der Absender sie zuriickgerufen hat. AuBerdem hat der MMS Service Pro- 
vider B nach dieser Erfindung die Moglichkeit, dem MMS User Agent B das Datum der Ausfiihrung des Riickruf-Be- 
fehls zu iibermitteln. 

[0048] Sollte die MMa schon an den Empfanger ausgeliefert worden sein, so kann das MMS User Agent B des Emp- 
f angers mit der o. g. emeuten Benachrichtigung (Notification) davon in Kenntnis gesetzt werden, daB der Absender die 55 
MMa zuriickrufen mochte. Das Loschen der MMa kann nach dieser Erfindung direkt im MMS User Agent B stattfinden, 
sofern dieses das Riickruf-Dienstmerkmal unterstiitzt. Je nach Implementierung dieses Dienstmerkmals im Endgerat, 
den Einstellungen des Benutzers, den Einstellungen des MMS Service Providers und/oder des Netzbetreibers kann das 
Loschen der MMa im Endgerat davon abhangig sein, ob die MMa bereits vom Empfanger "angefaBt" (z. B. geoffnet, ge- 
lesen, weitergeleitet, etc.) worden ist. Sinnvoll erscheint jedoch, nur solche MMs nach der Auslieferung zu loschen, wel- 60 
che noch nicht vom Empfanger "angefaBt" worden sind. Die MMb mit der Riickruf-Information muB dem MMS User 
Agent B nicht unbedingt zugestellt werden; sie kann schon im MMSEb geloscht werden. 

[0049] Hat der Empfanger (MMS User Agent B) der MMa noch keine Benachrichtigung iiber die MMa erhalten, etwa 
weil die MMb i^it der Riickruf-Information das MMS Relay B vor der riickzurufenden MMa erreicht, muB dieser auch 
nicht iiber eine vom Absender eingeleitete Riickruf- Aktion informiert werden. Statt dessen wartet das MMS Relay B vor- 65 
zugsweise, bis es die zum Riickruf referenzierte MMa erhalt und loscht diese beim Eintreffen, ohne den Empfanger zu 
benachrichtigen (vorausgesetzt, das MMS Relay B unterstiitzt das Riickruf-Dienstmerkmal). Altemativ kann die Lo- 
schung von MMa auch schon auf dem MMS Relay A erfolgen. 
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[0050] Der Auftraggeber des Ruckrufs (MMS User Agent A) wird gemaB der vorliegenden Erfindung iiber den Aus- 
gang und das Datum der Ausfiihrung der von ihm eingeleiteten Aktion vorzugsweise informiert, wenn die beteiligten 

MMS Service Provider dies ermoglichen. 

[0051] Um das gerade beschriebene Dienstmerkmal Ruckruf umsetzen zu konnen, schlagt die vorliegende Erfindung 
5 vor, daB eine oder mehrere der folgenden Informationen zusatzlich zwischen den beteiligten Instanzen (MMS User 
Agent A, MMS Relay A, MMS Relay B und MMS User Agent B) ausgetauscht werden: 

MMS User Agent A — ► MMS Relay A (beim Versenden einer MM) 

10 - Kennzeichnung, daB es sich bei einer MMb um einen Riickruf-Befehl handelt. 

- Identifikationsnummer der MMa, die zuriickgerufen werden soil. 

- Information, daiS der Ab sender eine Riickmeldung iiber den Ausgang der von ihm initiierten Riickrut- Aktion an- 
fordert. 

15 MMS Relay A MMS User Agent A (bei der Bestatigung nach dem Versendens einer MM) 

- Mitteilung des Service Providers, ob dieser das Ruckruf-Dienstmerkmal unterstiitzt. 

MMS Relay A MMS Relay B (nur dann notig, wenn Ab sender und Empfanger zu unterschiedlichen MMSEs geho- 
20 ren) 

- Kennzeichnung, daB es sich bei einer MMb um einen Riickruf-Befehl handelt. 

- Identifikationsnummer der MMa, zuriickgerufen werden soil. 

- Information, daB der Absender eine Riickmeldung iiber den Ausgang der von ihm initiierten Riickruf- Aktion an- 
25 fordert. 

[0052] Die Ubemiittlung der Infonnationen zwischen MMS Relay A und MMS Relay B ist davon abhangig, ob diese 

Informationen beim Versenden der MMb vorhanden waren. 

30 MMS Relay B — MMS User Agent B (bei der Benachrichtigung iiber eine eingetroffene MM), vorzugsweise in einer 

Nachricht 

- Information, wann der Riickruf ausgefiihrt wurde. 

- Information, daB eine zuvor durch eine Benachrichtigung angekiindigte MM^ nun nicht mehr zum Download be- 
35 reitliegt. Identifizierung der MMa, die im MMSEb geloscht worden ist, erfolgt anhand der Nachrichtenreferenz 

(Message Reference; URI). 
oder: 

- Information, daB eine bereits ausgelieferte MMa vom Absender zuriickgerufen wird. Identifizierung der MMa, 
die zuriickgerufen wird, erfolgt auf dem MMS User Agent B anhand der Nachrichten-ID 

40 - MMS User Agent B MMS Relay B (nach der Benachrichtigung): 

- Information, ob der Empfanger verstanden hat, daB eine zuvor durch eine Benachrichtigung angekiindigte MMa 
nun nicht mehr zum Download bereitliegt. 

oder: 

- Information, ob das EMS User Agent B den Riickruf (d. h. das Loschen) der MM^ erfolgreich durchfiihren 
45 konnte bzw. veranlaBt hat. 

- Information, ob der Empfanger dariiber informiert wurde (und/oder dem Ruckruf zugestimmt hat), daB eine be- 
reits heruntergeladene MMa zuriickgerufen wurde und daher nicht mehr im dem MMS User Agent B zugangigen 
Speicher des Endgerats (oder angeschlossenener Gerate/Speicherkarten) vorliegt. 

50 MMS Relay B — MMS Relay A (nur dann notig, wenn Absender und Empfanger zu unterschiedlichen EMSEs gehoren 

und wenn der Absender eine Riickmeldung angefordert hat) 

- Information, ob der Riickruf- Auftrag erfolgreich ausgefiihrt werden konnte. 

- Information, wann der Riickruf-Auftrag ausgefiihrt worden ist. 

55 — Information, ob der Riickruf-Auftrag automatisch durchgefiihrt wurde. 

- Information, ob der Empfanger iiber den Riickruf informiert wurde (und/oder dem Riickruf zugestimmt hat). 

- Information, daB eine bereits heruntergeladene MMa zuriickgerufen wurde und daher nicht mehr im dem MMS 
User Agent B zugangigen Speicher des Endgerats (oder angeschlossenener Gerate/Speicherkarten) vorliegt. 

- Identifikationsnununer der MMa, die zuriickgerufen wurde 

60 

MMS Relay A — ^ MMS User Agent A (beim Bericht) 

- Information, ob der Riickruf-Auftrag erfolgreich ausgefiihrt werden konnte. 

- Information, wann der Riickruf-Auftrag ausgefiihrt worden ist. 

65 - Information, ob der Riickruf-Auftrag automatisch durchgefiihrt wurde. 

- Information, ob der Empfanger iiber den Riickruf informiert wurde (und/oder dem Riickruf zugestimmt hat). 

- Information, daB eine bereits heruntergeladene MMa zuriickgerufen wurde und daher nicht mehr im dem MMS 
User Agent B zugangigen Speicher des Endgerats (oder angeschlossenener Gerate/Speicherkarten) vorliegt. 
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- Identifikationsnummer der MMa, die zuriickgerufen wurde. 

[0053] Nachfolgend werde mogliche Modifikationen der WAP Nachrichten fiir das Riickruf-Dienstmerkmal naher er- 
lautert: Um das Riickruf-Dienstmerkmal in die WAP Implementierung von MMS einzufugen, schlagt die vorliegende Er- 
findung eine Modifikation der WAP Nachrichten M-Send.req, M-Send.conf, M-Notification.ind, M-NotifyResp.req und 5 
M-Delivery.ind vor. In ihnen konnen nach dieser Erfindung verschiedene Header-Felder erganzt bzw. modifiziert wer- 
den. Nach WAP-203-WSP, Version 4-May-2000, Wireless Application Protocol, Wireless Session Protocol Specifica- 
tion, Chapter 8.4: "Header Encoding" besteht jedes Header-Feld aus einem (kodierten) Feld-Namen und einem (kodier- 
ten) Feld-Wert. Dabei existieren insgesamt vier Moglichkeiten den Feld-Wert zu codieren, wobei das erste Oktet des 
Feld-Wertes iiber die Art und Lange der Codierung entscheidet (siehe Tabelle 1 im Anhang). 10 

A.l. WAP Nachricht M-Send.req (vom MMS User Agent A zum MMS Relay A) 

[0054] Der Absender einer MM^ soil zum Ausdruck bringen, daB er seine MMa wieder zuruckrufen mochte. Dies ge- 
schieht durch das Versenden einer weiteren MM^ an den gleichen Empfanger. Zu diesem Zwecke kann in der WAP 15 
Nachricht M-Send.req, mit der die MMg verschickt wird, ein Header-Feld erganzt werden, das die Identifikationsnum- 
mer derjenigen MM tragi, die der Absender zuruckrufen mochte (IDl von MMa aus Fig. 2). Es wird vorgeschlagen, daB 
dieses Header-Feld den Namen X-Mms-Recall-ID und die hexadezimale Codierung 0 X 7F (dezimal: 127) tragi. Mes- 
sage-IDs werden konfomi zum Encapsulation-Standard (WAP-209-MMSEncapsulation, Release 2000; Wireless Appli- 
cation Protocol; WAP Multimedia Messaging Service; Message Encapsulation; MMS Proposed SCD 1.0) vorzugsweise 20 
als Text-String codiert. AuBerdem kann dem Absender einer mm mit Riickruf-Auftrag bevorzugt die Moglichkeit gege- 
ben werden, eine Riickmeldung anfordem zu konnen. Dazu wird vorgeschlagen, ein Header-Feld mit der zweckmaBigen 
Bezeichnung X-Mms-Request-Report und der hexadezimalen Codierung 0 X 85 (dezimal: 133) in die WAP Nachricht 
M-Send.req einzufiihren. Die Feld-Werte dieses Header-Feldes sind bevorzugt konfomi zum Encapsulation-Standard 
(s. o.) mit dem <Octetl28> fur "Riickmeldung wird gewiinscht" und <Octetl29> fur "Riickmeldung ist nicht erwiinscht" 25 
codiert. 

A.2 WAP Nachricht M-Send.conf (vom MMS Relay A zum MMS User Agent A) 

[0055] Mit dieser WAP Nachricht kann dem MMS User Agent A gemaB der vorliegenden Erfindung zusatzlich mitge- 30 
teilt werden, ob der Service I¥ovider A den Riickruf-Auftrag des Absenders (MMS User Agents A) angenommen hat. 
Dazu wird vorteilhafterweise vorgeschlagen, ein neues Header-Feld mit den Namen X-Mms-Supported-Feature und der 
hexadezimale Codierung 0 X 83 (dezimal: 131) in die WAP Nachricht M-Send.conf einzufugen. Vorzugsweise werden 
als Feld-Werte konform zum Encapsulation-Standard (s. o.) das <Octetl28> fiir eine Auftragsbestatigung und das <Oc- 
tetl30> fiir eine negative Riickmeldung benutzt (vergleiche Fig, 5). 35 

A.3 WAP Nachricht M-Notification.ind (vom MMS Relay B zum MMS User Agent B) 

[0056] Ist das MMS User Agent B bereits iiber eine zum Download bereitliegende MMa informiert worden, kann ge- 
maB der vorliegenden Erfindung in der WAP Nachricht M-Notification.ind ein neu definiertes Header-Feld mit der 40 
zweckmaBigen Bezeichnung X-Mms-Recalled-URI und der hexadezimalen Codierung 0 X 80 (dezimal: 128) zum Ein- 
satz kommen. Mit seiner Hilfe kann dem MMS User Agent B mitgeteilt werden, daB die MMa dem angegebenen 
URI nicht mehr langer zum Download bereit liegt, weil sie der Absender wieder zuriickgerufen hat. Der Feld-Wert dieses 
neu definierten Header-Feldes wird bevorzugt konform zum Encapsulation-Standard (s. o.) als Text-String codiert. Um 
den MMS User Agent B iiber den Zeitpunkt des Loschens informieren zu konnen, kann gemaB dieser Erfindung ein neu 45 
definiertes Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Date-of-Execution und der hexadezimalen Codie- 
rung 0 X 84 (dezimal: 132) erganzt werden. Die Feld-Werte fiir dieses Header-Feld werden bevorzugt nach dem Encap- 
sulation-Standard (s. o.) als Long-Integer codiert. 

[0057] In der URI der Benachrichtigung kann gemaB der vorliegenden Erfindung auf den Speicherplatz einer Standard- 
Text-Nachricht (z. B.: "Diese MM wurde vom Absender wieder geloscht.") verwiesen werden, mit der das MMS Relay 50 
B auch ein MMS User Agent B iiber einen ausgefuhrten Riickruf-Auftrag informieren kann, wenn dies das Riickruf- 
Dienstmerkmal nicht unterstiitzt (eiIso die neuen Header-Felder nicht erkennt) und versucht, eine MM von dem in der Be- 
nachrichtigung ausgewiesenen Speicherplatz herunterzuladen. 

[0058] Falls die MM^, die zuriickgerufen werden soil, bereits an das MMS User Agent B ausgeliefert worden ist, kann 
erfindungsgemaB die WAP Nachricht M-Notification.ind das in Abschnitt A. 1 definierte Header-Feld mit dem Namen X- 55 
Mms-RecaU-ID beinhalten. Das MMS User Agent B kann daraufhin umgehend mit Hilfe der Message-ID (ID2 aus Fig, 
2) das Loschen der MMa einleiten (vorausgesetzt es unterstiitzt das Riickruf-Dienstmerkmal). 

A.4 WAP Nachricht M-NotifyResp.req (vom MMS User Agent B zum MMS Relay B) 

60 

[0059] GemaB der vorliegenden Erfindung wird vorteilhafterweise vorgeschlagen, in der WAP Nachricht M-Notify- 
Resp.req optional ein neues Header-Feld einzufiigen, mit dessen Hilfe dem MMS Relay B mitgeteilt werden kann, ob das 
MMS User Agent B die Meldung iiber einen erfolgreich ausgefiihrten Riickruf-Auftrag verstanden hat. Zu diesem 
Zweck wird vorzugsweise das aus anderen WAP Nachrichten bekannte Header-Feld X-Mms-Status benutzt und ein 
neuer Feld-Wert definiert: Es wird vorgeschlagen, daB das <Octetl36> die Bedeutung "Recall-Feature supported" hat. 65 
[0060] Falls die riickzurufende MMa bereits an das MMS User Agent B ausgeliefert worden war, wird gemaB einer 
vorteilhaften Variante der vorliegenden Erfindung vorgeschlagen, in der WAP Nachricht M-NotifyResp.req das im En- 
capsulation-Standard (s. o.) definierte Header-Feld X-Mms-Status einzufiigen, mit dem dem MMS Relay mitgeteilt wer- 
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den kann, ob der Riickruf-Auftrag des Ab senders erfolgreich auf dem MMS User Agent B ausgefuhrt werden konnte 
oder nicht. Dazu ist allerdings auch hier eine Erweiterung dieses Header- Feldes notwendig: Die Riickmeldung wird be- 
vorzugt mit den beiden neuen Feld-Werten <Octetl32> fur "Riickruf-Auftrag wurde erfolgreich ausgefuhrt" und <Oc- 
tetl33> fur "Riickruf-Auftrag konnte nicht ausgefuhrt werden" realisiert. 

5 

A.5 WAP Nachricht M-Delivery.ind (vom MMS Relay A zum MMS User Agent A) 

[0061] Weiterhin wird vorgeschlagen, vorzugsweise das in Abschnitt A.4 erweiterte Header-Feld X-Mms-Status auch 
hier einzufiigen. Mit seiner Hilfe kann dem Absender (MMS User Agent A) mitgeteilt werden, ob sein Riickruf-Auftrag 
10 erfolgreich ausgefuhrt werden konnte oder nicht, wenn auch hier die neuen Feld-Werte <Octetl32> fiir "Riickruf-Auf- 
trag wurde erfolgreich ausgefiihrt" und <Octetl33> fiir "Riickruf-Auftrag konnte nicht ausgefuhrt werden" benutzt wer- 
den (vergleiche Fig, 5). AulSerdem kann der Absender iiber das Datum der Ausftihrung seines Riickruf-Auftrages mit 
Hilfe des in Abschnitt A. 3 definierten Header-Feldes mit der zweckmaBigen Bezeichnung X-Mms-Date-of-Execution in- 
formiert werden. 

15 

B) Andem-Dienstmerkmal 

[0062] Ein Benutzer des MMS, der eine Multimedia Message MM^ abgeschickt hat und diese bereits verschickte MM 
spater verandem mochte, kann gemaB dieser Erfindung eine neue MWLq zusammen mit der Information verschicken, daB 
20 diese MMb eine zuvor verschickte MMa andern, insbesondere ersetzen, soil. Unten stehende Ausfiihrungen gelten ganz 
allgemein fiir Anderungen einer ersten Nachricht MMa, so auch z. B. fiir das nachtragliche Anhangen einer Datei an eine 
zuvor versendete MMa. 

[0063] Eine Anderung von MMa dadurch realisiert werden, dal3 der Absender eine neue MM^ verfaBt, die einen 
Anderungsbefehl beinhaltet, und diese an den gleichen Empfanger wie die zuvor verschickte MMa schickt. Zur Identi- 

25 fizierung der MMa wird vorteilhaferweise die IDl der zuvor verschickten und jetzt zu verandemden MMa benutzt. Die 
MMb niit der Anderungs-Information gelangt zunachst zum MMS Relay A. Hier wird iiberpriift, ob die MMa der 
IDl noch im Zustandigkeitsbereich (MMSEa) des Service Providers A ist, oder ob sie sich schon im MMS Eg des Ser- 
vice Providers B befindet. Beides ist moglich, je nach dem, ob vom Absender der MMa ein Zeitpunkt fiir die friihest- 
mogliche Auslieferung oder eine Giiltigkeitsdauer angegeben worden ist. Sobald die MMa in einem MMSE der beteilig- 

30 ten MMS Service Provider ausfindig gemacht worden ist, kann das Andern der MMa durch die MMg vom zustandigen 
MMS Relay eingeleitet werden. Praktisch realisiert wird diese Aktion vorzugsweise durch das Loschen der alten MMa 
und das Weiterleiten der neuen MMb an den Rmpfanger. Der MMS Service Provider hat gemaB dieser Erfindung die 
Moglichkeit, den MMS User Agent B iiber einen gegebenenfalls ausgefiihrten Anderung s-Vorgang und/oder iiber das 
Datum der Ausfuhrung des Anderungs-Vorgangs ("diese mm wurde aktualisiert am. . .") in Kenntnis zu setzen. 

35 [0064] Hat der Empfanger (MMS User Agent B) der MMa noch keine Benachrichtigung iiber die MMa erhalten, etwa 
weil die MMg mit dem Andern ngs- Auf trag das MMS Relay B vor der zu andernden MMa erreicht, muB dieser auch 
nicht zwingend iiber eine vom Absender eingeleitete Anderungs- Aktion informiert werden. Statt des sen kann das MMS 
Relay B warten, bis es die zu andernde MMa erhalt und andert, insbesondere ersetzt, diese beim Eintrefifen durch die 
MMb (vorausgesetzt, das MMS Relay B unterstiitzt das Riickruf-Dienstmerkmal). Der MMS Service Provider kann nach 

40 dieser Erfindung das MMS User Agent B bei der Zustellung der MM^ davon in Kenntnis setzen, daB sie eine vom Ab- 
sender nachtraglich geanderte MM ist und wann diese Anderung ausgefiihrt worden ist. 

[0065] Falls das MMS User Agent B des Empfangers schon iiber die fiir ihn im MMSE^ bereitliegende MMa mittels 
einer Benachrichtigung (Notification) informiert worden ist und sich die MMa noch im Zustandigkeitsbereich des Ser- 
vice Providers B befinden soUte, kann gemaB dieser Erfindung das MMS User Agent B mit einer emeuten Benachrich- 
45 tigung (Notification) davon in Kenntnis gesetzt werden, daB der Absender seine MMa nachtraglich geandert hat und 
wann diese Anderung ausgefuhrt worden ist. 

[0066] SoUte die MMa schon an den Empfanger ausgeliefert worden sein, so kann entweder das MMS User Agent B 
zunachst eine Benachrichtigung vom Service Provider B erhalten, daB eine MMb zum Ersatz der MMa vorliegt, oder die 
MMb mit dem Anderungs- Auftrag kann dem MMS User Agent B unmittelbar zugestellt werden. Unabhangig davon, ob 

50 die MMb im PUSH-Modus oder im PULL-Modus zugestellt worden ist, kann das Andern, insbesondere das Ersetzen, 
der MMa durch die MMb direkt im MMS User Agent B stattfinden, sofem dies das Andern-Dienstmerkmal unterstiitzt. 
Je nach Implementierung dieses Dienstmerkmals im Endgerat, den Einstellungen des Benutzers, den Einstellungen des 
Service Providers und/oder des Netzbetreibers kann das Andern, insbesondere das Ersetzen, von MMa (und damit im 
Falle des PULL-Modus: zusatzlich das Anfordem von MMt^) im Endgerat davon abhangig sein, ob die MMa bereits vom 

55 Empfanger "angefaBt" (z. B. geoffnet, gelesen, weitergeleitet, etc.) worden ist. SinnvoU erscheint, insbesondere solche 
MMs automatisch (d. h. ohne Riickfrage mit dem Empfanger) zu andern, welche noch nicht vom Empfanger "angefaBt" 
worden sind. Hat der Empfanger die MMa schon aus der Posteingangsbox genommen, weitergeleitet oder gelesen, so 
kann er zumindest noch dariiber informiert werden, daB der Absender mit MMb die zuvor verschickte MMa andern 
wollte. 

60 [0067] Der Absender/Auftraggeber (MMS User Agent A) kann gemaB einer vorteilhaften Variante der Erfindung iiber 
den Ausgang und das Datum der Ausfiihrung der von ihm eingeleiteten Anderungs- Aktion informiert werden, wenn die 
beteiligten MMS Service Provider dies unterstiitzen. 

[0068] Die Identifikation von MMa auf der Empfangsapplikation MMS User Agent B) kann insbesondere anhand ei- 
ner Nachrichtenreferenz erfolgen, welche vorzugsweise ein URI ist, unter dessen Speicherplatz eine Standard-Text- 
65 Nachricht des empfangerseitigen Service Providers B abgespeichert ist. Die URI setzt sich bevorzugt aus der Identifika- 
tionsnummer IDl von MMa oder aus von einer empfangerseitigen Netzwerkelement (MMS Relay B) festgelegten zwei- 
ten Identifikationsnummer (ID2) zusammen. 

[0069] Um das gerade beschriebene Dienstmerkmal Andern, insbesondere Ersetzen, umsetzen zu konnen, wird gemaB 
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der vorliegenden Erfindung vorgeschlagen, daB eine oder mehrere der foLgenden Informationen zusatzlich zwischen den 
beteiligten Instanzen (MMS User Agent A, MMS Relay A, MMS Relay B und MMS User Agent B) ausgetauscht wer- 
den: 

MMS User Agent A — ► MMS Relay A (beim Versenden einer MM) 5 

- Kennzeichnung, dal3 es sich bei einer MM^ um einen Anderungs-Befehl handelt. 

- Identifikationsnummer der MMa, die geandert werden soil. 

- Information, daB der Absender eine Riickmeldung iiber den Ausgang der von ihm eingeleiteten Anderungs-Ak- 
tion anfordert. 10 

MMS Relay A MMS User Agent A (bei der Bestatigung nach dem Versenden einer MM) 

- Mitteilung des Service Providers, ob dieser das Andern-Dienstmerkmal unterstiitzt. 

15 

MMS Relay A — ► MMS Relay B (nur dann notig, wenn Absender und Empfanger zu unterschiedlichen MMSEs geho- 

ren) 

- Kennzeichnung, dal3 es sich bei einer MM^ um einen Anderungs-Befehl handelt. 

- Identifikationsnummer der MMa, die geandert werden soli. 20 

- Information, daB der Absender eine Riickmeldung iiber den Ausgang der von ihm eingeleiteten Anderungs-Ak- 
tion anfordert 



[0070] Die Ubermittlung der Informationen zwischen MMS Relay A und MMS Relay B ist davon abhangig, ob diese 
Informationen beim Versenden der MMg vorhanden waren. 25 

MMS Relay B — ► MMS User Agent B (bei der Benachrichtigung iiber eine eingetroflfene MM), vorzugsweise in einer 

Nachricht 



— Information, daB der Absender eine zum Download bereitliegende MM^ durch eine neue MMg geandert hat. Die 30 
Identifizierung beider MMs erfolgt anhand der Message References (URIs) zu den betroffenen MMs. 

- Information, wann die zum Download bereitliegende MMa durch die neue MMg geandert wurde. 
oder: 

- Information, daB der Absender eine bereits zuvor ausgelieferte MMa durch eine neue MM^ andern, insbesondere 
ersetzen, mochte. Die Identifizierung der MMa, die aktualisiert wird, erfolgt anhand der individuellen Message ID 35 
und die Identifizierung der MMb, welche die MMa andem, insbesondere ersetzen, soil, erfolgt anhand der Message 
Reference (URI). 

MMS User Agent B — >- MMS Relay B (nach der Benachrichtigung) 

40 

— Information, ob der Empfanger iiber den Anderungs-Auftrag informiert werden konnte. 

[0071] Wurde im Fall des PULL-Modus der Empfanger von einer vorliegenden MMb niit Anderungs-Auftrag unter- 
richtet, so kann er diese mittels der bekannten Mechanismen vom MMS Relay B beziehen. Im Fall des PUSH-Modus 
wird der Download der MMb vom MMS Service Provider (und nicht vom Emp^nger initiiert). In diesem Fall konnen 45 
die beiden vorigen Schritte (Benachrichtigung und deren Bestatigung) entfahen. 



MMS Relay B — ► MMS User Agent B (bei der Zustellung einer MM) 

- Kennzeichnung, daB die MMb einen Anderungs-Auftrag enthalt, der auf dem MMS User Agent B ausgefuhrt 50 
werden soil. 

- Information, welche bereits ausgelieferte MMa geandert, insbesondere ersetzt, werden soU. Die Identifizierung 
der MMa erfolgt anhand der individuellen Message ED. 

oder: 

- Information, daB die soeben ausgelieferte MMb eine nachtraglich geanderte MM ist. 55 

- Information, wann MM^ vom Absender geandert worden ist. 

MMS User Agent B MMS Relay B (nach der Zustellung einer MM) 

- Information, ob der Anderungs-Auftrag erfolgreich ausgefiihrt werden konnte. 60 

- Information, ob der Anderungs-Auftrag automatisch durchgefuhrt wurde. 

- Information, ob der Empfanger iiber den Anderungs-Vorgang informiert wurde (und/oder der Anderung zuge- 
stimmt hat). 



MMS Relay B —y MMS Relay A (nur dann notig, wenn Absender und Empfanger zu unterschiedfichen MMSEs gehoren 65 

und wenn der Absender eine Riickmeldung angefordert hat) 

- Information, ob der Anderungs-Auftrag erfolgreich ausgefiihrt werden konnte. 
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- Information, wann der Anderungs-Auflxag ausgefiihrt worden ist. 

- Information, ob der Anderungs-Auftrag automatisch durchgefiihrt. wurde. 

- Information, ob der Empf anger iiber die Anderung informiert wurde (und/oder der Anderung zugestimmt hat). 

- Information, ob eine bereits heruntergeladene MMa geandert, insbesondere ersetzt, wurde oder aber die MMa 
5 vor dem Ersetzen noch nicht ausgeUefert worden war. 

- Identifikationsnummer der MMa, die geandert, insbesondere ersetzt, wurde. 

MMS Relay A MMS User Agent A (beim Bericht) 

10 - Information, ob der Anderungs-Auftrag erfolgreich ausgefiihrt werden konnte. 

- Information, wann der Anderungs-Auftrag ausgefiihrt worden ist. 

- Information, ob der Anderungs-Auftrag automatisch durchgefuhrt wurde. 

- Information, ob der Empfanger iiber die Anderung informiert wurde (und/oder der Anderung zugestimmt hat). 

- Information, ob eine bereits heruntergeladene MMa geandert, insbesondere ersetzt, wurde oder aber die MMa 
15 vor der Anderung noch nicht ausgeliefert worden war. 

- Identifikationsnummer der MMa, die geandert, insbesondere ersetzt, wurde. 

[0072] Nachfolgend werde mogliche Modifikationen der WAP Nachrichten fiir das Andem-Dienstmerkmal naher er- 
lautert: Um das Andern-Dienstmerkmal in die WAP Implementierung von MMS einzufiihren, wird gemaB der vorliegen- 
20 den Erfindung eine Modifikation der WAP Nachrichten M-Send.req, M-Send.conf, M-Notification.ind, M-Notify- 
Resp.req, M-Retrieve.conf, M-Acknowledge.ind und M-Delivery.ind vorgeschlagen. In ihnen werden vorteilhafterweise 
analog zum Vorgehen in Abschnitt A (Riickruf-Dienstmerkmal) verschiedene Header-Felder erganzt bzw. modifiziert: 

B . 1 WAP Nachricht M-Send.req ( vom MMS User Agent A zum MMS Relay A) 

25 

[0073] Der Absender einer mm soil zum Ausdruck bringen konnen, dal3 er nachtraglich seine bereits verschickte MMa 
durch eine neue MM^ andem, insbesondere ersetzen, mochte. Bevorzugt wird zu diesem Zweck in der WAP Nachricht 
M-Send.req, mit der die neue MM^ verschickt wird, ein weiteres Header-Feld erganzt, das die Identifikationsnummer 
derjenigen MM tragi, die durch MM^ geandert, insbesondere ersetzt, werden soil (namlich EDI von MMa aus Fig. 2). Es 

30 wird vorgeschlagen, daB dieses Header-Feld den Namen X-Mms-Replace-ID und die hexadezimale Codierung 0x81 
(dezimal: 129) tragt. Message-IDs werden konfbrm zum Encapsulation-Standard (s. o.) vorzugsweise als Text-String co- 
diert. AuBerdem wird dem Absender einer MM mit Anderungs-Auftrag vorzugsweise die Moglichkeit gegeben, eine 
Riickmeldung anzufordem. Dazu wird vorgeschlagen, das in Abschnitt A.l definierte Header-Feld mit der zweckmaBi- 
gen Bezeichnung X-Mms-Request- Report in die WAP Nachricht M-Send.req einzufiihren. Die Feld-Werte dieses Hea- 

35 der-Feldes werden vorteilhafterweise konform zum Encapsulation-Standard (s. o.) mit dem <Octetl28> fiir "Riickmel- 
dung wird gewiinscht" und <Octetl29> fiir "Riickmeldung ist nicht erwiinscht" codiert. 

B.2 WAP Nachricht M-Send.conf (vom MMS Relay A zum MMS User Agent A) 

40 [0074] Mit dieser WAP Nachricht kann dem MMS User Agent A gemaB der vorliegenden Erfindung mitgeteilt werden, 
ob der Service Provider A dem Anderungs-Auftrag des Absenders (MMS User Agents A) entsprechend gehandelt hat 
bzw. handeln konnte. Dazu wird vorgeschlagen, das in Abschnitt A.2 zum Zwecke des Riickruf-Dienstmerkmals einge- 
fiihrte Header-Feld mit der zweckmaBigen Bezeichnung X-Mms- Supported- Feature vorzugsweise auch hier zu nutzen. 
Als Feld-Werte kommen dann entweder das <Octetl29> fiir "Replace-Feature supported" oder das <Octetl30 > fiir "no 

45 support" zum Einsatz. 

B.3 WAP Nachricht M-Notification.ind (vom MMS Relay B zum MMS User Agent B) 

[0075] Nach dieser Erfindung wird in der WAP Nachricht M-Notification.ind vorzugsweise ein neu definiertes Header- 
50 Feld mit der zweckmaJSigen Bezeichnung X-Mms-Replaced-URl und der hexadezimalen Codierung 0 x 82 (dezimal: 
130) erganzt. Mit seiner Hilfe kann dem MMS User Agent B nach einer bereits erfolgten Benachrichtigung mitgeteilt 
werden, daB die MMa unter dem angegebenen URI nicht mehr langer zum Download bereit liegt, well sie der Absender 
durch eine neu MM^ mit einem anderen URI ersetzt hat. Der Feld- Wert dieses neu definierten Header- Feldes wird vor- 
teilhafterweise konform zum Encapsulation-Standard (s. o.) als Text-String codiert. Um den MMS User Agent B iiber 
55 den Zeitpunkt der Aktualisierung informieren zu konnen, wird gemaB einer vorteilhaften Variante der Erfindung das in 
Abschnitt A. 3 neu definierte Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Date-of-Execution erganzt. 
[0076] Wenn sich die zu andemde, insbesondere zu ersetzende, MMa schon auf dem MMS User Agent B befindet, 
wird vorteilhafterweise gemaB dieser Erfindung in der WAP Nachricht M-Notification.ind das in Abschnitt B.l neu de- 
finierte Header-Feld mit der zweckmaBigen Bezeichnung X-Nms-Replace-ID und der hexadezimalen Codierung 0x81 
60 (dezimal: 129) erganzt. Das MMS User Agent B erkennt daran, daB die zum Download bereitliegende MM^ einen An- 
derungs-Befehl fiir die MMa mit der entsprechenden Message- ID beinhaltet. Der Download der MM^ kann daraufhin je 
nach den Einstellungen des Benutzers, den Einstellungen des MMS Service Providers und/oder des Netzbetreibers ent- 
weder im Push-Modus oder im Pull-Modus eingeleitet werden. 

65 B.4 WAP Nachricht M-Retrieve.conf (vom MMS Relay B zum MMS User Agent B) 

[0077] Wenn die zu andernde MMa schon im MMSE^ durch MM^ geandert werden konnte, bietet sich gemaB der vor- 
liegenden Erfindung an, in der WAP Nachricht M-Retrieve.conf, mit der MMb an den MMS User Agent B iibermittelt 
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wird, vorzugsweise das Encapsulation- Standard (s. o.) definierte erweiterte Header-Feld X-Mms- Status mit dem Feld- 
Wert <Octetl34> fur "replace successful" und das in Abschnitt A. 3 neu definierte Header-Feld mit der zweckmaBigen 
Bezeichnung X-Mms-Date-of-Execution einzufiigen. Dadurch kann das MMS Relay B dem MMS User Agent B signa- 
lisieren, daB die MMb eine nachtraglich geanderte MM ist und wann der Anderungs-Auftrag des Absenders im Zustan- 
digkeitsbereich des MMSEb ausgefuhrt worden ist. 5 
[0078] Wenn sich die zu andemde MMa schon auf dem MMS User Agent B befindet, ist es gemaB der vorliegenden 
Erfindung vorteilhaft, in der WAP Nachricht M-Retrieve.conf ebenfalls das in Abschnitt B.l definierte Header-Feld mit 
dem Namen X-Mms-Replace-ID zu erganzen. Mit ihm kann das Andem der MMa auf dem MMS User Agent B mit Hilfe 
der Message-ID eingeleitet werden (s. Fig. 2), falls das MMS User Agent B das Andern-Dienstmerkmal unterstiitzt. An- 
dernfalls wird dem Empfanger dadurch nur angezeigt, daB der Ab sender die MMa durch die neue MMb andem woUte. 10 

B.5 WAP Nachricht M-Acknowledge.ind (vom MMS User Agent B zum MMS Relay B) 

[0079] GemaB dieser Erfindung wird in einer vorteilhaften Weiterbildung vorgeschlagen, in der WAP Nachricht M- 
Acknowledgement.ind das im Encapsulation-Standard (s. o.) definierte Header-Feld X-Mms-Status einzufiigen. Damit 15 

dem MMS Relay mitgeteilt werden kann, ob der Anderungs-Auftrag des Absenders im PULL-Modus erfolgreich ausge- 
fiihrt werden konnte oder nicht, ist auch hier eine Erweiterung dieses Header-Feldes (analog zu dem Vorgehen in Ab- 
schnitt A, Riickruf-Dienstmerkmal) notwendig: Die Riickmeldung wird in dieser Erfindung vorteilhafterweise mit den 
beiden neuen Feld-Werten <Octetl34> fiir "Anderungs-Auftrag wurde erfolgreich ausgefiihrt" und <Octetl35> fiir "An- 
derungs-Auftrag konnte nicht ausgefuhrt werden" realisiert. 20 

B.6 WAP Nachricht M-NotifyResp.ind (vom MMS User Agent B zum MMS Relay B) 

[0080] GemaB dieser Erfindung wird vorgeschlagen, in der WAP Nachricht M-Notif3^Resp.ind das im Encapsulation- 
Standard (s. o.) definierte Header-Feld X-Mms-Status einzufiigen. Damit dem MMS Relay mitgeteilt werden kann, ob 25 
der Anderungs-Auftrag des Absenders im PUSH-Modus erfolgreich ausgefuhrt werden konnte oder nicht, ist auch hier 
eine Erweiterung dieses Header-Feldes (analog zu dem Vorgehen in Abschnitt A, Ruckruf-Dienstmerkmal) notwendig: 
Die Riickmeldung wird in dieser Erfindung vorzugsweise mit den beiden neuen Feld-Werten <Octetl34> fiir "Ande- 
rungs-Auftrag wurde erfolgreich ausgefiihrt" und <Octetl35> fiir "Anderungs-Auftrag konnte nicht ausgefiihrt werden" 
realisiert. 30 

B.7 WAP Nachricht M-Delivery.ind (vom MMS Relay A zum MMS User Agent A) 

[0081] Weiterhin wird vorgeschlagen, das in Abschnitt B.5 erweiterte Header-Feld X-Mms-Status auch hier einzufii- 
gen. Mit seiner Hilfe kann dem Absender (MMS User Agent A) mitgeteilt werden, ob sein Anderungs-Auftrag erfolg- 35 
reich ausgefuhrt werden konnte oder nicht, wenn auch hier die neuen Feld-Werte <Octetl34> fiir "Andenmgs-Auftrag 
wurde erfolgreich ausgefiihrt" und <Octetl35> fiir "Anderungs-Auftrag konnte nicht ausgefiihrt werden" benutzt werden 
(vergleiche Fig. 5). AuBerdem wird der Absender vorteilhafterweise iiber das Datum der Ausfiihrung seines Anderungs- 
Auftrages mit Hilfe des in Abschnitt A. 3 definierten Header-Feldes mit der zweckmaBigen Bezeichnung X-Mms-Date- 
of-Execution informiert. 40 
[0082] Fig, 5 zeigt noch einmal die sieben, vorteilhafterweise neu eingefiihrten Header-Felder einschlieBHch der Co- 
dierungen von Feld-Name und Feld-Wert. In Fig, 6 ist das um neue Feld-Werte erweiterte Header-Feld X-Mms-Status 
dargestellt. In den Fig. 7 und 8 sind die Header-Felder der altemativen Realisierungsmoglichkeiten (Ausfiihrungsbei- 
spiele C und D, s. u.) dargestellt. Die um die entsprechenden Header-Felder erganzten WAP Nachrichten sind im Anhang 
in den Tabellen 2 bis 8 aufgelistet. AUe Veranderungen und Erganzungen in den Tabellen zum heutigen Stand der Tech- 45 
nik sind dabei dick eingerahmt. 

Binare Codierung 

[0083] In den folgenden Ausfiihrungsbeispielen wird detailliert auf die in den WAP Nachrichten benutzten Header- 50 
Felder eingegangen. Dabei wird beispielhaft folgendes Szenario angenommen: MMS User Agent A verschickt eine 
MMa bestehend aus einem Text und einem JPEG-Bild an einen Empfanger und wiU diese spater zuriickrufen (Beispiel 
A) bzw. durch eine neue MMb ersetzen (Beispiel B). 

55 



60 



65 
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M-Send.req (MMS User Agent A MMS Relay A) 
X-Mms-Message-Type : m-send-req 
^ X-Mms-Transaction-ID: 10 
X-Mms-Version : 1.0 

Date: Thu, 26 Oct 2000 12:12:19 +0100 
10 From: abc@siemens.de 
To : xyz@siemens , de 
Subject: multimedia message a 

15 

Content "Type: multipart/related; boundary=" 

_=_NextPart_000_ " 

20 

_ =_Next Part_000_ 

Content-Type : text/plain; name= ''meeting . txf 
Con tent- Transfer-Encoding : quo ted-prin tabl e 

Hallo xyz, 

30 

hier ist die gewiinschte Agenda 
fiir unser nachstes Meeting. 

35 

GruE, abc 

40 

^=^NextPart^000^ 

Con tent- Type : image/ j peg; name= "agenda . jpg " 
Content -Transfer-Encoding: hase64 
Content-ID: <1725782> 

50 

_=_NextPart_000_ — 

[0084] Das MMS User Agent A des Benutzers mit der Adresse abc@siemens.de verschickt eine MMa bestehend aus 
55 einem Text (MIME content type "text/plain") und einem JPEG-Bild (MIME content type "image/jpeg") an das MMS 
User Agent B des Benutzers mit der Adresse xyz@siemens.de. Die zu diesem Zweck benutzte "WAP Nachricht M- 
Send.req tragt beispielsweise die Transaction-ID 10. Das MMS Relay vergibt daraufhin eine individuelle Identifikations- 
nummer fiir die gesendete MMa und bestatigt mit der WAP Nachricht M-Send.conf , daB die WAP Nachricht M-Send.req 
fehlerfrei an das MMS Relay iibertragen worden ist. 

60 
65 
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M-Send.conf (MMS Relay A — ^ MMS User Agent A) 
X-Mms-Message-Type: m-send-conf 
X-Mms - Trans ac t ion -ID: 10 
X-Mms -Vers ion: 1.0 ... 
X'Mms-Response-Status : ok 

Message-ID: AAAA. llll&mms-relayOl . siemens.de 



X-Mms "Recall -ID: AAAA. llll@nims- 

relay 01 . Siemens . de 

X-Mms -Reques t -Report : Yes 
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[0085] In den beiden WAP Nachrichten M-Send.req und M-Send.conf kommt die gleiche Transaction-ID zum Einsatz. 
Damit kann die WAP Nachricht M-Send.conf mit der Message-ID am MMS User Agent A eindeutig der dazugehorigen 
WAP Nachrichten M-Send.req zugeordnet werden, wodurch die individuelle Identifikationsnummer 15 
AAAA.llll @mms-relay01. siemens.de der verschickten MMa zugeordnet werden kann. Das MMS Relay A hat fiir die 
MMa in diesem Beispiel fur die Schnittstelle MMS User Agent A/MMS Relay A die individuelle Identifikationsnummer 
AAAA. 11 1 1 @mms-relay01. siemens.de vergeben. Sie steht im Header-Feld Message-ID. 

Beispiel A 20 

Ruckruf 

[0086] Der Absender der MMa mochte diese (zwei Stunden spater) wieder zuriickrufen. Dies geschieht nach dieser Er- 

findung mit Hilfe einer neuen MM^, die an den gleichen Empf anger geschickt wird, wie die MM^, die zuriickgerufen 25 
werden soil. An dieser Stelle kommt vorteilhafterweise in der WAP Nachricht Msend.req das gemaB der vorliegenden 
Erfindung neu definierte Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Recall-ID zum Einsatz, in das die 
Message-ID der MMa, die zuriickgerufen werden soli, eingetragen wird (IDl in Fig, 2). AuBerdem enthalt die WAP 
Nachricht M-Send.req vorteilhafterweise das ebenfalls gemaB der vorliegenden Erfindung neu definierte Header-Feld 
mit der zweckmaBigen Bezeichnung X-Mms-Request-Report, mit dem eine Ruckmeldung iiber den erteilten Ruckruf- 30 
Auftrag angefordert werden kann (wie in diesem Beispiel gezeigt). In der WAP Nachricht M-Send.req sind bei einem 
Riickruf-Auftrag vorzugsweise nur die Header-Felder und kein weiterer multimedialer Tnhalt ("Message-Body") enthal- 
ten. 

M-Send.req (MMS User Agent A MMS Relay A) 35 

X-Mms -Mess age- Type : m-send-req 
X-Mms-Transact ion-ID: 16 
X-Mms - Versi on: 1.0 

Date: Thu, 26 Oct 2000 14:12:19 -hOlOO 
From : ahc&sal . Siemens . de 
To : xyz @sa 1 . si emens . de 



40 



45 



50 



55 



Subject: recall of multimedia message a 
Con tent- Typ e: text /plain 

[0087] Auch der Empfang der WAP Nachricht M-Send.req mit dem Riickruf-Befehl in MMb wird vorteilhafterweise 

vom MMS Relay umgehend mit einer WAP Nachricht M-Send.conf quittiert. In ihr ist die vom MMS Relay vergebene 
Message-ID fiir die MMg (hier: AAAA.2222@mms-relay01.siemens.de) enthalten. Femer enthalt sie vorteilhafterweise 60 
das gemaB der vorliegenden Erfindung neu definierte Header-Feld X-Mms- Supported- Feature mit dessen Hilfe dem 
MMS User Agent A angezeigt werden kann, ob der Service Provider A das Riickmf-Dienstmerkmal unterstiitzt (wie hier 
gezeigt) oder nicht. 

65 
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M-Send.conf (MMS Relay A — ^ MMS User Agent A) 

X-Mms -Message-Type: m-send-conf 
^ X-Mms-Transaction-ID: 16 

X-Mms-Versi on: 1.0 

X-Mms-Response-Status : ok 
10 Message- ID: AAAA. 2222@inms-relay01 . Siemens .de 



15 



30 



35 



40 



45 



50 



55 



X-Mms ' Support ed'Fea ture : 

recall 



[0088] Beim Austausch von WAP Nachrichten auf der Empfangsseite (Schnittstelle zwischen MMS Relay B und 
MMS User Agent B) muB unterschieden werden, ob der MMS User Agent B 

20 1. noch nicht iiber eine eingetroffene mm informiert worden ist, oder 

2. zwar benachrichtigt worden ist, aber die mm noch nicht abgerufen hat, oder 

3. die MM schon erhalten hat. 

[0089] Im ersten und zweiten Fall konnen die MMa und auch die MMb, die den Riickruf-Befehl enthalt, im Zustandig- 

25 keitsbereich des Service Providers B (MMSE^) geloscht werden. Im ersten Fall muB der Empfanger davon nicht einmal 
in Kenntnis gesetzt werden. Im zweiten Fall soUte der MMS User Agent B hingegen durch den Service Provider B vor- 
zugsweise dariiber informiert werden konnen, daB die MM^ nicht mehr langer zum Download fur ihn bereit liegt, wenn 
der Absender sie nachtraglich zuriickgerufen hat. Dazu kann gemaB dieser Erfindung die WAP Nachricht M-Notificati- 
on.ind benutzt werden: 



2. Fall: M-Notitication.ind (MMS Relay B — ► MMS User Agent B) 
X-Mms 'Message-Type : m-no ti fi ca ti on-ind 
X-Mms -Transact ion- ID: 20 
X-Mms -Vers ion : 1.0 
From : abc@sal . si emens . de 
X-Mms-Message-Class : Personal 
X-Mms-Message-Size : 42 
X-Mms -Expiry: 3600 

X-Mms -Con tent -Location : http: //mms - 
relay 02 . Siemens . de/ default-recall -message 



X-Mms -Reca lied- URI : http : //mms - 
relay02.siemens.de/BBBB. 3333 

X-Mms -Date-Of -Execution: Thu, 26 Oct 2000 14:14:54 
+ 0100 



[0090] In der WAP Nachricht M-Notification.ind kann fiir die Identifizierung der zuriickgerufenen MMa nur der URI 
60 benutzt werden, da das MMS Relay zu diesem Zeitpunkt noch keine Message-ID fiir die zuriickgerufene MMa vergeben 
hat (dies geschieht erst mit dem Download). Die Header-Feld X-Mms-Recalled-URI und X-Mms-Date-Of- Execution 
unterscheiden diese Riickruf-Benachrichtigung von einer "herkommlichen" Benachrichtigung. Das Header-Feld X- 
Mms-Content-Location verweist in diesem Beispiel auf einen URI, unter des sen Speicherplatz vorteilhafterweise eine 
Standard-Text-Nachricht des Service Providers B (z. B.: "Die MM ist vom Absender wieder geloscht worden.") zu fin- 
65 den ist. Damit konnen auch MMS User Agents, die die neuen Header-Felder des Riickruf-Dienstmerkmals nicht verste- 
hen, nachtraglich uber einen ausgefiihrten Riickruf-Auftrag informiert werden. 

[0091] Mit der WAP Nachrichten M-NotifyResp.req wird der korrekte Empfang der WAP Nachricht M-Notificati- 
on.ind bestatigt. Das Header-Feld X-Mms-Status tragt in diesem Beispiel einen der gemaB der vorliegenden Erfindung 
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neu definierten Eintrage (namlich "recall feature supported"), mit dem das MMS Relay B dariiber in Kenntnis gesetzt 
werden kann, daB das MMS User Agent B die zweite Benachrichtigung mit der Information iiber den Riickruf verstanden 
hat. 

(noch) 2. Fall: M-NotifyResp.req (MMS User Agent B MMS Relay B) 

X-Mms -Message - Type : m-noti fyresp -reg 

X'Mms-Transaction-ID: 20 

X-Mms 'Vers i on: 1.0 

X-Mms - Status : recall feature 

supported 

[0092] Wenn aber die MMa, die geloscht werden soil, bereits an das MMS User Agent B iibermittelt worden ist (dritter 
Fall), beinhaltet vorteilhafterweise die WAP Nachricht M-Notification.ind zweckmaBigerweise nicht die Benachrichti- 
gung iiber den bereits erfolgten Riickruf, sondern den Riickruf-Befehl selbst und zwar in Form des Header- Feldes mit der 
zweckmaBigen Bezeichnung X-Mms-Recall-ID, in dem die Identifikationsnummer der MMa eingetragen wird, die zu- 
riickgerufen werden soli. Hier wird vorzugsweise die Identifikationsnummer (und nicht der URI) benutzt, weil sie (in 
dem hier beschriebenen dritten Fall) nach dem zuvor erfolgten Download sowohl dem MMS Relay B als auch dem MMS 
User Agent B bekannt ist. 

3. Fall: M-Notification.ind (MMS Relay B MMS User Agent B) 
X-Mms -Message-Type : m-notification-ind 
X-Mms -Transaction- ID: 25 
X-Mms - Versi on: 1.0 
From : abc@sal . si emens . de 
X-Mms -Message-Class : Personal 
X-Mms-Message-Size : 42 
X-Mms -Expiry: 3600 

X-Mms -Content-Location: http: //mms- 
relay02 . Siemens . de/de fault-recall-message 
X-Mms -Recall -ID: BBBB . 3333@mms- 
relay 02 . Siemens . de 

[0093] Das Header-Feld X-Mms-Content-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicher- 
platz eine Standard-Text-Nachricht des Service Providers B (z. B.: "Der Absender mochte die mm mit der Message-ID 
BBBB.3333@mms-relay02.siemens.de zuriickrufen.") zu finden ist. Damit konnen auch MMS User Agents, die die 
neuen Header-Felder des Riickruf-Dienstmerkmals nicht verstehen, nachtragUch iiber einen vom Absender verschickten 
Riickruf-Auftrag informiert werden. 

[0094] Um hervorzuheben, daB die MMa an dieser Schnittstelle eine andere Message-ID tragen kann, wurde in diesem 
Ausfiihrungsbeispiel als Wert BBBB.3333@mms-relay02.siemens.de gewahlt (entspricht ID2 von MMa in Fig* 2). 

(noch) 3. Fall: M-NotifyResp.req (MMS User Agent B MMS Relay B) 

X-Mms -Message - Typ e: m-noti fyresp -reg 
X-Mms - Trans a ction-ID: 25 
X-Mms - Versi on: 1.0 
X-Mms-Status: recall suc- 
cessful 
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[0095] Das MMS User Agent B schickt bei diesem Ausfiihrungsbeispiel mit der WAP Nachricht M-NotifyResp.req 
eine Riickmeldung zuriick an das MMS Relay B. Dazu wird vorteilhafterweise das in dieser Erfindung erweiterte Hea- 
der-Feld X-Mms-Status aus dem Encapsulation- Standard (s. o.) benutzt. In diesem Ausfiihrungsbeispiel konnte die 
MMa auf dem MMS User Agent B geloscht werden, was mit dem Feld-Wert "recall successful" ausgedruckt wird. Im 
MMS Relay B kann von der Transaction-ID (hier: 25) des WAP Nachrichten-Paares auf die Message-ID (hier: 
BBBB.3333@nims-relay02.siemens.de) der geloschten MMa geschlossen werden. Dadurch ist das Verfassen einer 
Riickmeldung moglich, falls dies vom Absender gewiinscht und vom Service Provider B unterstiitzt wird. 

M-Delivery.ind (MMS Relay A — ► MMS User Agent A) 
X-Mtns -Message-Type: m-delivery-ind 

X'Mms "Message- ID: AAAA.2222@imas-relay01 . Siemens . de 

X-Mms -Version : 1.0 

To : ahc&sa 1 . si emens . de 

Date: Thu, 26. Oct 2000 14:14:09 +0100 



X-Mms -Status : recall suc- 
cessful 



25 [0096] Falls der Absender eine Riickmeldung fiir den von ihm initiierten Riickruf-Auftrag wiinscht, kann das MMS 
Relay A mit der WAP Nachricht M-Delivery.ind eine Riickmeldung zuriick an das MMS User Agent A schicken. In dem 
Feld Message-ID steht die ID des Riickruf-Auftrages. Fur den Status des ROckrufes wird hier ebenfalls vorteilhafter- 
weise das erweiterte Header-Feld X-Mms-Status benutzt, in dem das erfolgreiche Loschen der MMa n^it dem Feld-Wert 
"recall successful" bestatigt wird. Da dem MMS User Agent A der Zusammenhang zwischen der Message- ED des Riick- 

30 ruf-Auftrages und der Message-ID der MM^, die zuriickgerufen werden sollte, bekannt ist, kann dem Absender mitge- 
teilt werden, ob sein Riickrut-Auftrag erfolgreich ausgefiihrt werden konnte oder nicht (sofem die beteiligten MMS Ser- 
vice Provider dies unterstiitzen). 



Beispiel B 
Andem 



[0097] In diesem Beispiel mochte der Absender seine MMa (eine Stunde nach dem Verschicken) aktualisieren: Von 
den urspriinglichen verschickten zwei Elementen soil nur noch das JPEG-Bild (MIME content type "image/jpeg") erhal- 

40 ten bleiben. AuBerdem soil der Betreflf in "Agenda fiir unser Meeting" geandert werden. 

[0098] GemaB dieser Erfindung wird eine neue MMb an den gleichen Empf anger geschickt wie die zuvor verschickte 
MMa, die geandert bzw. ersetzt werden soil. Dazu wird vorteilhafterweise das gemaB der vorliegenden Erfindung neu 
definierte Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Replace-ID benutzt, in das die Message-ID der 
MMa eingetragen wird. AuBerdem enthalt vorteilhafterweise die WAP Nachricht M-Send.req das ebenfalls gemaB der 

45 vorliegenden Erfindung neu definierte Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Request- Report, mit 
dem eine Riickmeldung iiber den erteilten Anderungs-Auftrag angefordert werden kann (wie in diesem Beispiel gezeigt). 
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M-Send.req (MMS User Agent A MMS Relay A) 

X-Mms -Message -Type : m-send-reg 
X-Mms - Trans ac t ion -ID: 32 
X-Mms -Vers ion : 1.0 

Date: Thu, 26 Oct 2000 13:12:11 -hOlOO 

From : abcQsal . si emens , de 

To: xyz@sal.siemens.de 

X-Mns -Replace- ID: AAAA. llllQmms- 

relayOl . Siemens . de 

X-Mms -Requ es t -Repor t : Yes 

Subject: Agenda fiir unser Meeting 

Content-Type: multipart /related; boundary=" 

_=^NextPart_023_ " 

^_ =_NextPart_ 02 3_ 

Content-Type : image/ jpeg; name= "agenda . jpg " 
Con ten t-Transfer-Encoding : base64 
Content-ID: <1725782> 

_=_NextPart_023_-- 

[0099] Auch der Empfang dieser WAP Nachricht M-Send.req, welche die MMb mit dem Anderungs-Befehl in sich 
tragi, wird bevorzugt vom MMS Relay umgehend mit einer WAP Nachricht M-Send.conf quittiert. In ihr ist zweckma- 

Bigerweise die vom MMS Relay vergebene Message-ID der MMb (hier: AAAA.5555@mms-relay01.siemens.de) und 
das ebenfalls gemaB der vorliegenden Erfindung neu definierte Header-Feld X-Mms-Supported- Feature enthalten, mit 
dessen Hilfe dem MMS User Agent A angezeigt werden kann, ob der Service Provider A das Andern-Dienstmerkmal un- 
terstutzt Oder nicht. Die beiden WAP Nachrichten tragen in diesem Beispiel die Transaction-ID32. 

M-Send.conf (MMS Relay A — ^ MMS User Agent A) 

X-Mms-Message-Type : m-send-conf 
X-Mms - Trans ac t ion- ID: 32 
X-Mms - Versi on: 1,0 
X-Mms -Response- Status : ok 

Message-ID: AAAA. 5555@mms-relay01 . siemens.de 

X-Mms -Support ed-Fea ture : 

replace 

[0100] Beim Austausch von WAP Nachrichten auf der Empfang sseite (Schnitts telle zwischen MMS Relay B und 
MMS User Agent B) muB unterschieden werden, ob der MMS User Agent B 

1. noch nicht iiber eine eingetroffene MM informiert worden ist, oder 

2. zwar benachrichtigt worden ist, aber die MM noch nicht abgerufen hat, oder 
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3. die MM schon erhalten hat. 



[0101] Im ersten und zweiten Fall kann die MM^ ini Zustandigkeitsbereich des Service Providers B (MMSEg) durch 
die MMb geandert, insbesondere ersetzt, werden. Die Erfindung ermoglicht, daB der Empfanger im ersten Fall sowohl 
bei der Benachrichtigung als auch beim Download dariiber in Kenntnis gesetzt wird, dal3 es sich um eine nachtraglich ge- 
anderte, insbesondere ersetzte, mm handelt und wann der Anderungs-Auftrag ausgefuhrt worden ist. Bevorzugt kann im 
zweiten Fall der Service Provider B den MMS User Agent B sofort nach dem Ausfiihren des Anderungs-Auftrages im 
MMSEb dariiber informieren, daB der Absender MMa durch eine neue MMb aktualisiert hat und wann diese Aktualisie- 
rung vorgenommen worden ist. Nach dieser Erfindung soil diese Benachrichtigung vorzugsweise mittels der WAPNach- 
richt M-Notification.ind erfolgen, in der fiir die Identifizierung der geanderten, insbesondere ersetzten, MMa nur der URI 
benutzt werden kann, da das MMS Relay B zu dieseni Zeitpunkt noch keine Message-ID fiir die MM^ vergeben hat (dies 
geschieht erst mit dem Download der MMa) . Die Header- Felder X-Mms-Replaced-URI und X-Mms-Date-Ot-Execution 
unterscheiden diese Riickruf-Benachrichtigung von einer "herkommlichen" Benachrichtigung. Das Header-Feld X- 
Mms-Content-Location zeigt an, wo die MMb mit dem nun aktuellen Inhalt auf dem Server zu finden ist. 

2. Fall: M-Notification.ind (MMS Relay B MMS User Agent B) 

X-Mms-Message-Type : m-notification-ind 
X'Mms - Transa ction-ID: 35 
X-Mns-Version : 1.0 
From : abcQsal . si emens . de 
25 X-Mms-Messag-e-Class: Personal 
X-Mns -Message -Size : 45 
X-Mms -Expiry: 3600 

X-Mms-Content-Location: http: //nuns- 
relay02 , Siemens . de/BBBB, 4444 



10 



15 



20 



30 



35 



40 



X-Mms -Repl aced - UK J ; http : //mms - 
relay02 . Siemens . de/BBBB . 3333 

X-Mms-Date-Of -Execution: Thu, 26 Oct 2000 13:15:09 
+0100 



[0102] Mit der WAP Nachricht M-NotifyResp.req wird vorteilhafterweise der korrekte Empfang der WAP Nachricht 
45 M-Notification.ind vom MMS User Agent B bestatigt, vgl. Fig, 2. Das Header-Feld X-Mms-Status tragt in diesem Bei- 
spiel einen gemaB der vorliegenden Erfindung neu definierten Eintrag (namlich "replace feature supported") mit dem das 
MMS Relay B dariiber in Kenntnis gesetzt wird, daB das MMS User Agent B die zweite Benachrichtigung mit der Infor- 
mation iiber den ausgefiihrten Anderungs-Auftrag verstanden hat. 

50 (noch) 2. Fall: M-NotifyResp.req (MMS User Agent B — ^ MMS Relay B) 

X-Mms -Message-Type: m-notifyresp-req 
X-Mms - Transa ction-ID: 35 
X-Mms -Version : 1.0 

X-Mtns -Status : replace feature sup- 
ported 

60 ^ 

[0103] Wenn aber die MMa, die geandert werden soil, bereits an das MMS User Agent B iibermittelt worden ist (dritter 
Fall), beinhaltet nach dieser Erfindung die WAP Nachricht M-Notification.ind vorteilhafterweise nicht die Benachrichti- 
gung iiber eine bereits erfolgte Anderung, sondern den Anderungs-Befehl selbst und zwar in Form des Header-Feldes mit 
65 der zweckmaBigen Bezeichnung X-Mms-Replace-ID, in dem die Identifikationsnummer der zu andemden, insbesondere 
zu ersetzenden, MMa eingetragen wird. Daraufhin kann vom MMS User Agent B der Download der MMb entweder im 
Push-Modus oder im Pull-Modus mit Hilfe des WSP GET Befehls eingeleitet werden. Das Header-Feld X-Mms-Con- 
tent-Location verweist in diesem Beispiel auf einen URI, unter dessen Speicherplatz eine Standard-Tbxt-Nachricht des 
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Service Providers B (z. B.: "Der Absender mochte die MM mit der Message-ID BBBB.3333 @ mms-relay02.siemens.de 
nachtraglich andem.") zu linden ist. Damit konnen auch MMS User Agents, die die neuen Header-Felder des Riickruf- 
Dienstmerkmals nicht verstehen, nachtraglich iiber einen vom Absender verschickten Riickruf-Auftrag informiert wer- 
den. 

3. Fall: M-Notification.ind (MMS Relay B — ^ MMS User Agent B) 

X-Mms "Message-Type : m-noti fx ca tion-ind 

X-Mms - Trans a ction-lD: 38 

X-Mms-Versi on: 1,0 

From : abc@sal . Siemens . de 

X-Mms -Message-Class : Personal 

X-Mms -Message -Size: 45 

X-Mms -Expiry : 3600 

X-Mms - Con tent -Loca tion: http:/ /mms - 
relay02 . Siemens . de/default-replace-message 



X-Mms -Replace- ID: BBBB.3333&mms- 
relay 02 . si emens . de 
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[0104] Als Antwort auf den WSP GET Befehl, mit dem der URI an das MMS Relay B geschickt wird, erhalt das MMS 30 
User Agent B die MMb mit dem geanderten Titel und dem geanderten multimedialen Inhalt (nur noch ein JPEG-Bild) 
zum Andem bzw. Ersetzen von MMa in der WAP Nachricht M-Retrieve.conf zugestellt. Auch in der WAP Nachricht M- 
Retrieve.conf soli vorteilhafterweise das Header-Feld mit der zweckmaBigen Bezeichnung X-Mms-Replace-ID erganzt 
werden. Damit kann direkt auf dem MMS User Agent B die MMa durch die MMg geandert, insbesondere ersetzt, wer- 
den, falls das MMS User Agent B das Andem-Dienstmerkmal unterstiitzt. Abhangig vom gewahlten Zustellungs-Modus 35 
wird in der WAP Nachricht M-Retrieve.conf die Transaction-ID aus der WAP Nachricht M-Notification.ind iibemom- 
men (PUSH-Modus) oder eine neue vergeben (PULL- Modus). 



(noch) 3. Fall: M-Retrieve.conf (MMS Relay B MMS User Agent B) 
X-Mms -Message-Type : m-retrieve-conf 
X-Mms-Transaction-ID: 38 bzw. 48 
Message-ID: BBBB. 4444@mms-relay02.siemens.de 
X-Mms-Versi on: 1.0 

Date: Thu, 26 Oct 2000 13:12:11 +0100 
From : ahcSsal . Siemens . de 
X-Mms -Mess age -CI ass : Personal 
X-Mms -Message-Si ze: 42 
X-mns -Expiry: 3600 



X-Mms -Replace-ID: BBBB. 3333Qmms- 
r el ay 02 . si emens . de 



Subject: Agenda fur unser Meeting 
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Content-Type: multipart /related; boundary="' 
^ _=_NextPart_023_ " 

_=_NextPart_023_ 

10 Content-Type: image/ jpeg; name = "agenda . jpg" 
Content-Transfer-Encoding: base64 
Content-ID: <1 725782> 

15 



30 



35 



55 



60 



20 _==_NextPart_023_ — 

[0105] Um hervorzuheben, daB die MMa an dieser Schnittstelle eine andere Message-ID txagen kann, wurde in diesem 
Ausfuhrungsbeispiel als Wert BBBB.3333@mms-relay02.siemens.de gewahlt (entspricht ID2 in Fig, 2). 

25 Bei Zustellung von MM^ im PULL-Modus 

3. FaU: M-Acknowledge.ind (MMS User Agent B MMS Relay B) 

X-Mms -Message - Type : m-acknowl edge -ind 
X-Mms -Transaction- ID : 48 
X-Mms -Vers ion : 1.0 



X-Mms - Status : replace suc- 
cessful 



[0106] Erfolgte die Zustellung der MMb im PULL-Modus, schickt das MMS User Agent B vorzugsweise mit der WAP 
40 Nachricht M-Acknowledge.ind eine Riickmeldung zuriick an das MMS Relay B. Dazu wird das in dieser Erfindung er- 
weiterte Header-Feld X-Mms-Status benutzt. In diesem Ausfuhrungsbeispiel konnte die MMa auf dem MMS User 
Agent B durch die neue MMq ersetzt werden, was mit dem Feld-Wert "replace successful" ausgedriickt wird. Im MMS 

Relay B kann von der Transaktions-ID (Transaction-ID) (hier: 48) des WAP Nachrichten-Paares M-Retrieve.conf und 
M-Acknoledge.ind auf die Message-ID (hier: BBBB.3333@mms-relay02.siemens.de) der ersetzten MM^ geschlossen 
45 werden. Dadurch ist das Verfassen einer Riickmeldung mogHch, falls dies voni Absender verlangt und vom Service Pro- 
vider B unterstiitzt wird. 

Bei Zustellung von MMb PUSH-Modus 

50 3. Fall: M-NotifyResp.req (MMS User Agent B MMS Relay B) 

X-Mms -Message-Type: m-notifyresp-req 
X-Mms - Tran saction-ID: 38 

X-Mms -Vers ion : 1.0 



X'Mms - Status : replace suc- 
cessful 



[0107] Erfolgte die Zustellung der MMB im PUSH-Modus, bestatigt das MMS User Agent B den korrekten Empfang 
von MMb vorzugsweise mit der WAP Nachricht M-NotifyResp.req. Dazu wird bevorzugt das in dieser Erfindung erwei- 
terte Header-Feld X-Mms-Status benutzt. In diesem Ausfuhrungsbeispiel konnte die MMa ^uf dem MMS User Agent B 
65 durch die neue MMb ersetzt werden, was mit dem Feld-Wert "replace successful" ausgedriickt wird. Im MMS Relay B 
kann von der Transaction-ID (hier: 38) des WAP Nachrichten-Triples M-Notification.ind M-Retrieve.conf und M-Noti- 
fyResp.req auf die Message-ID (hier: BBBB.3333@mms-relay02.siemens.de) der ersetzten MMa geschlossen werden. 
Dadurch ist das Verfassen einer Riickmeldung moglich, falls dies vom Absender verlangt und vom Service Provider B 
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unterstiitzt wird. 

M-Delivery.ind (MMS Relay A MMS User Agent A) 
X-Mms -Message-Type : m-del ivery- ind 

X-Mms -Message- ID: AAAA. 5555©imns-relay01 . Siemens, de 

X-Mms - Version : 1.0 

To : abc@sal . Siemens . de 

Date: Thu, 26 Oct 2000 13:12:11 +0100 
X-Mms-Status : replace suc- 
cessful 



[0108] Das MMS Relay A kann mit der WAP Nachricht M-Delivery.ind eine Ruckmeldung zuriick an das MMS User 
Agent A schicken. In dem Feld Message-ID steht die ID des Anderungs-Auftrages. Fiir den Status des Anderungs-Auf- 20 
trages wird hier vorzugsweise ebenfalls das erweiterte Header-Feld X-Mms-Status benutzt, in dem das erfolgreiche An- 
dern der MMa durch MM^ mit dem Feld- Wert "replace successful" bestatigt wird. Da dem MMS User Agent A der Zu- 
sammenhang zwischen der Message-ID des Anderungs-Auftrages und der Message-ID der MMa, die zuriickgerufen 
werden sollte, bekannt ist, kann dem Absender mitgeteilt werden, ob sein Anderungs-Auftrag erfolgreich ausgefiihrt 
werden konnte oder nicht (sofem die beteiligten MMS Ser\ice Provider dies unterstutzen). 25 

Beispiel C 

Alternative fur das Ubermitteln einer Status-Information 

30 

[0109J In den beiden zuvor beschriebenen Ausfuhrungsbeispielen wird eine Ruckmeldung iiber den Ausgang eines er- 
teilten Riickruf- bzw. Anderungs-Auftrages vom MMS User Agent B zum MMS Relay B (bei Service Provider B) mit 
den WAP Nachrichten M-NotifyResp.ind (PUSH-Modus) oder M-Acknowledgement.ind (PULL-Modus), bzw. vom 

MMS Relay A zum MMS User Agent A (bei Service Provider A) mit der WAP Nachricht M-Delivery.ind iibertragen. 
Dazu warden neue Feld-Werte in das Header-Feld X-Mms-Status eingefiihrt. Dieses Vorgehen ist zwar effizient, jedoch 35 
nicht ganz konform zur bisherigen Nutzung des Header-Feldes X-Mms-Status. Deshalb wird im folgenden ein alternati- 
ves Ausfuhrungsbeispiel fiir das Ubermitteln einer Ruckmeldung beschrieben. Das Absenden sowie das Ausfiihren eines 
Riickruf- oder Anderungs-Auftrages bleibt dabei wie in Beispiel A und Beispiel B beschrieben zweckmaBigerweise un- 
verandert. 

[0110] Mit dieser Alternative wird das Header-Feld X-Mms-Status (so wie es im Encapsulation Standard (s. o.) ur- 40 
spriinglich vorgesehen ist) weiterhin ausschlieBUch dazu benutzt, den Absender iiber den Zustand der zuletzt verschick- 
ten mm (also derjenigen, die den Riickruf- oder Anderungs-Auftrag beinhaltete) zu informieren und nicht (wie unter 

Ausfiihrungsbeispiel A und B beschrieben) iiber den Ausgang eines Riickruf- oder Anderungs-Auftrages. Fiir diesen Fall 
wird deshalb ein weiteres Header-Feld definiert, mit dem der Absender iiber den Ausgang seines Riickruf- oder Ande- 
rungs-Auftrages in Kenntnis gesetzt werden kann. Es wird vorgeschlagen, dieses neue Header-Feld mit dem Namen X- 45 
Mms-Original-Message-Status zu versehen und ihm die hexadezimale Codierung 0 X 86 (dezimal: 134) zu geben. Wei- 
terhin wird vorgeschlagen, z. B. als Feld-Werte <Octetl28> fiir "Die MM wurde erfolgreich zuriickgerufen", <Oc- 
tetl29> fiir "Der Riickruf der nam ist fehlgeschlagen", <Octetl30> fiir "Die MM wurde erfolgreich geandertbzw. ersetzt" 
und <Octetl31> fiir "Das Andem bzw. Ersetzen der mm ist fehlgeschlagen" zu benutzen. Fig, 7 zeigt das in dieser Al- 
ternative vorgestellte Header-Feld. 50 

Beispiel D 

Alternative fiir das iibermitteln einer Riickmeldung 

55 

[0111] In den Beispielen A und B wurde die MMa, ^uf die sich die Riickmeldung bezieht, iiber das Ergebnis des Riick- 
ruf- bzw. Anderungs-Auftrages anhand der Message-ID von MMb und anhand der Transaktion-IDs in den WAP Nach- 
richten M-NotifyResp.ind oder M-Acknowledge.ind identifiziert. 

[0112] Denkbar ist auch, die Nachrichten- ID derjenigen MMa, die zuriickgerufen oder geandert, insbesondere ersetzt, 
worden ist, direkt mit den WAP Nachrichten M-NotifyResp.ind oder M-Acknowledgement.ind (an Service Provider B), 60 
bzw. M-Delivery.ind (von Service Provider A) zu iibertragen. Dazu wird vorgeschlagen, ein neues Header-Feld einzu- 
fiihren, welches beispielsweise die zweckmaBige Bezeichnung X-Mms-Original-Message-ID tragi, und ihm die hexade- 
zimale Codierung 0 X 87 (dezimal: 135) zu geben. Die Feld-Werte dieses neuen Header-Feldes beinhalten bevorzugt die 
Message-ID der Original-MMA und werden gemaB des Encapsulation-Standards (s. o.) als Text-String codiert. Fig, 8 
zeigt das in dieser Alternative vorgestellte Header-Feld. 65 
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Anhang 
Tabelle 1 

Moglichkeiten der Feld- Wert-Codierung nach WAP-203-WSP, Version 4-May-2000; Wireless Application Protocol, Wi- 
reless Session Protocol Specification; Chapter 8.4: "Header Encoding" 



Erstes Oktet 

Hoe FaIH— Wat*^ Afis 


Mogliche Kombinatio- 


Anzahl der 
nacnzolg'enaen Ojcfce- 
ten 


0. . .30 


31 


0. . .30 


31 


1 


> 30 


32 . . .127 (far Text) 


96 


> 0 


128. . .255 


128 


0 
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Tabelle 2 



WAP Nachricht M-Send.req (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Inhalt 


Koxomentare 


X-Mms- 

Message-Type 


m-send-req 


Zwingend. 
Spezifiert den 
Transaktionstyp . 


X-Mms- 

Tr ansae t i on- 
ID 


Ein eindeutiger 
Identif izierer 


Zwingend. 

Diese Transaktions-ID 
identif iziert nur das M- 
Send.req und die 
korrespondierende Antwort. 


X-Mms-MMS~ 
Version 


Versionsnuiraner 


Zwingend . 

Die MMS Versionsnummer . Gemafi 
dieser Spezif ikation ist die 
Version 1.0. 


Date 


Absendedatum 


Optional . 

Ankunftszeit der Nachricht am 
MMS Server. Der MMS Server 
wird dieses Feld generieren 
wenn es nicht vom Terminal zur 
Verfugung gestellt wird. 


From 


Abs ender adr e s s e 


Zwingend. 

Dieses Feld MUSS in einer 
Nachricht vorhanden sein, die 
an einen Empf anger 
ausgeliefert wird. Dieses Feld 
KANN vom Absenderklienten 
erzeugt werdnen oder KANN am 
MMS Server eingefugt werden, 
indem „ insert-an-address- 
token'' benutzt wird. 
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To 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Cc 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt • 


Bcc 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Subject 


Betref f 


Optional . 


X-Mms- 

Message- 

Class 


Privat 1 
Anzeige | 
Information | 
Auto 


Optional . 

„Auto'* bezeichnet eine 
Nachricht, die automatisch vom 
Klienten generiert wird. Wenn 
die Nachrichtenklasse „Auto'* 
ist, SOLL der 

Ursprungsterminal NIGHT einen 
Aus 1 i e f erungsber i cht oder 
Lesebericht anfordern. 
Wenn des Feld nicht vorhanden 
ist, interpretiert der 
Empfanger die Nachricht als 
privat . 


X-Mms- 
Recall-ID 


ID 


Optional . 

Diese ID SOLL immer vorhanden 
sein, wenn^ ein Absender eine 
zuvor versendete MM 
zurtickrufen will. Bezeichnet 
die Nachricht en- ID der MM, die 
cxii ^^jjocsiiuexT zurucKruren wiJLx . 


X-Mms- 
Replace-ID 


ID 


Optional . 

Diese ID SOLL iininer vorhanden 
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sein, wenn ein Absender eine 
zuvor versendete MM andern 
will. Bezeichnet die 
Nachrichten-ID der MM, die ein 
Absender andern will. 


X-Mms- 
Request- 
Report 


Ja 1 Nein 


Optional . 

Bezeichnet, ob der Absender 
einen Bericht darliber 
anfordert, ob ein Ruckruf- 
oder ein Anderungs-Auf trag 

erfolgreich ist oder nicht. 


X-Mins-Expiry 


Zeitdauer, 
wahrend der die 
Nachricht im 
Server 
gespeichert 
wird Oder 
Zeitpunkt, zu 
dem die 
Nachricht 
geloscht wird. 


Optional . Voreinstellung : 
Maximum, das Feld hat zwei 
Formate, entweder absolut oder 
intervallbezogen . 


X-Mms- 
Delivery- 
Time 


Zeitpunkt der 
gewunschten 
Auslief erung 


Optional . Voreinstellung: 
sofort. Bezeichnet die fruhest 
mogliche Auslief erung der 
Nachricht an den EmpfSnger. 
Das Feld hat zwei Formate, 
entweder absolut oder 
intervallbezogen . 


X-Mms- 
Priority 


Niedrig | 
Normal 1 T-Tr^nVi 


Optional. Voreinstellung: 
iMormax 


X-Mins- 
Sender- 


Verbergen | 
Zeigen 


Optional . Voreinstellung : 
Zeige dem Empfanger 
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Visibility 




Adresse/Telefonnximmer des 
AbsenderS/ auSer der Absender 
hat eine geheime 
Niimmer /Adresse . 
Verbergen = zeige keine 
AdressG. Zeige = zeige sogar 
geheime Adresse. 


X-Mms- 

Delivery- 

Report 


Ja 1 Nein 


Optional. Voreinstellung wird 
bestimnt, wenn der Service 
angefordert wird. 
Spezif iziert , ob der Nutzer 
einen Auslief erungsbericht von 
jedem Empf anger mochte. Wenn 
Nachrichtenklasse „Auto'' ist, 
SOLL das Feld immer vorhanden 
sein und der Wert SOLL „No" 
sein. 


X-Mms -Read- 
Reply 


Ja 1 Nein 


Optional. Spezif iziert , ob der 
Nutzer einen Lesebericht von 
jedem EmpfSnger in Form einer 
neuen Nachricht mochte. Wenn 
Nachrichtenklasse „Auto'' ist, 
SOLL das Feld immer vorhanden 
sein und der Wert SOLL „No" 
sein , 


Content -Type 


Inhaltstyp- 
Identif izierer 


Zwingend. Der Inhaltstyp der 
Nachricht . 
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Tabelle 3 

WAP Nachricht M-Send.conf (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Znhalt 


Koxnmentare 


X-Mms- 

Message-Type 


iti-send-conf 


Zwingend. Identif iziert den 
Nachrichtentyp . 


X-Mms- 

Transaction- 
ID 


Ein 

eindeutiger 
Identif izierer 


Zwingend. Diese Transaktions- 
ID identif iziert nur das M- 
Send. con f und die 
korrespondierende Anforderung. 


X-Mms-MMS- 
Version 


Vers i onsnummer 


Zwingend. 

Die MMS Vers i onsnummer . GemaS 
dieser Spezif ikation ist die 
Version 1.0. 


X-Mms- 

Supported- 

Feature 


Riickruf | 
Andern | Keine 
Unterstutzung 


Optional . 

Dieses Feld SOLL immer 
vorhanden sein, uiti anzuzeigen, 
ob ein Service Provider fahig 
ist, ein oder mehrere der 
Dienstmerkmale zu 
unterstiitzen. 


X-Mms- 

Charging- 

Amount 


Charge 


Optional . 
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X-Mms- 

Response- 

Status 


Status Code 


Zwingend. MMS spezifischer 
Status . 


Message- ID 


ID 


Optional. Dies ist eine 
eindeutige, der Nachricht 
zugeordnete Ref erenz . Diese ID 
SOLL immer vorhanden sein, 
wenn der MMS Server die 
Nachricht akzeptiert . 
Die ID ermoglicht einem 
Kunden, Auslief erungsberichte 
mit zuvor vers ende ten 
Nachricht abzugleichen. 
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Tabelle 4 

WAP Nachricht M-Notification.ind (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Inhalt 


KoRmentare 


X -Mms -Me s s age - 
Type 


m-notif ication- 
ind 


Zwingend. Spezifiziert den 
Trans aktionstyp . 


X-Mitis- 

Tr ansae t i on- 1 D 


Ein eindeutiger 
Identif izierer 


Zwingend. Identif iziert die 
Benachrichtigung und die 
nachfolgende Transaktion die 
durch die folgende M- 
NotifyResp abgeschlossen 
wird. 


X-Mms-MMS- 
Version 


Vers i onsnummer 


Zwingend. 

Die MMS Versionsnuunmer . Gemafi 
dieser Spezif ikation ist die 
Version l.O, 


From 


Absenderadresse 


Optional • 

Wenn das Verbergen der 
Adresse des Absenders vor dem 
Empfanger unterstiitzt wird, 
wird der MMS Server dieses 
Feld nicht eineiti 
Nachrichtenkopf hinzufugen. 


X-Mms- 

Recalled-URI 


URI 


Optional . 

Bezeichnet ein URI, das nicht 
mehr gultig ist. 


X-Mms~ 

Replaced-URI 


URI 


Optional . 

Bezeichnet ein URI, das nicht 
mehr gultig ist. 


X-Mms«-Date-Of - 
Execution 


Datxim 


Optional • 

Bezeichnet das Datum, an dem 
ein Ruckruf- oder ein 
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Anderungs-Auf trag ausgeftihrt 
wurde. 


X-Mms-Recall- 
ID 


ID 


Optional . 

ID SOLL immer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM zuruckrufen 
will, die schon an den User 
Agent ausgeliefert wurde. 
Bezeichnet die Nachrichten-ID 
der MM, die ein Absender 
zuruckrufen will. 


X-Mms-Replace- 
ID 


ID 


Optional . 

ID SOLL iininer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM andern will, 
die schon an den User Agent 
(UA) ausgeliefert wurde. 
oezeicnnec aie JMacnncnLen— ID 
der MM, die ein Absender 
andern will. 



X-Mms -Message- 
Class 


Privat 1 
Anzeige | 
Information | 
Auto 


Zwingend . 


X-Mms -Message- 
Size 


Grofie der 
Nachricht 


Zwingend. Voile Grofie der 
Nachricht in Okteten. 


X -Mms - Expi ry 


Zeitdauer , 
wahrend der die 
Nachricht 
zuganglich ist. 


Zwingend. Das Feld hat nur 
ein Format: intervallbezogen. 


X-Mms - Cont en t - 
Location 


URI 


Zwingend. Dieses Feld 
identif iziert den Ort der 
Nachricht . 
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Tabelle 5 

WAP Nachricht M-NotifyResp.req (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Inhalt 


Koinmentare 


X-Mms- 

Message-Type 


m-send-conf 


Zwingend . 
Identif iziert den 
Nachrichtentyp . 


X-Mms- 

Transaction- 
ID 


Ein eindeutiger 
Identif izierer 


Zwingend. Diese 
Transaktions-ID 
identif iziert nur das 
M- Send. con f und die 
entsprechende 
Anf orderung , 


X-Mms-MMS- 
Version 


Versionsnuiraner 


Zwingend. 
Die MMS 

Vers i onsnummer . GemSS 
dieser Spezif ikation 
ist die Version 1.0. 


X-Mms- Status 




Zuruckgewiesen | 

Heruntergeladen | 
Verschoben | 
Ruckruf erfolgreich | 
Ruckruf f ehlgeschlagen | 
Andern erfolgreich | 
Andern f ehlgeschlagen | 
Ruckruf -Di ens tmerkmal 
unterstutzt | Andern- 
Di ens tmerkmal 
unterstutzt 


Zwingend . 

Nachrichtenstatus . 


X-Mms -Report- 
Allowed 


Ja/Nein 


Optional . 

Voreinstellung : Ja . 
Senden des 

Ablief erungsberichts 
dem Nutzer erlaubt. 
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Tabelle 6 

WAP Nachricht M-Retrieve.conf (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Izihalt 


Komnentare 


X-Mois- 

Mes sage -Type 


m-retrieve-conf 


Zwingend . 
Spezifiziert den 
Nachrichtentyp . 


X-ltos- 

Transact ion- 
ID 


Ein eindeutiger 
Identif izierer 


Optional . Identif ziert 
entweder die Transaktion, die 
durch M-Notification ohne M- 
NotifResp gestartet wurde, 
Oder eine neue Transaktion, 
wenn eine auf geschobene 
Auslieferung erwiinscht wurde . 
Die neue Transaktions-ID ist 
optional . 


Message-ID 


ID 


Optional, Dies ist eine 
eindeutige, einer Nachricht 
zugeordnete Ref erenz . Diese ID 
SOLL iitimer vorhanden sein, 
wenn der Auftraggeber eine 
Gelesen-Antwort anf order te 
Die ID ermoglichet einem 
Kunden gelesene Berichte mit 
zuvor versendeten Nachrichten 
abzugleichen . 


X-Mms-MMS- 
Version 


Ver s ionsnummer 


Zwingend. Die MMS 

Vers ionsnummer . GemaS dieser 

Spezif ikation ist die Version 

1.0, 


Date 


Sendedatum 


Zwingend . 



32 



DE 101 04 713 A 1 



From 


Abs ender adr es se 


Optional . 

Wenn das Verbergen der 
Senderadresse vor dem 
Empfanger untersttitzt wird, 
wird der MMS Server dieses 
Feld nicht zu einem 
Nachrichtenkopf hinzufugen. 


To 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Cc 


Adresse #1 


Optional . 

Jede Anzahl von Adressf eldern 
ist erlaubt. 


Subject 


Betref f 


Optional . 


X-Mms- 
Replace-ID 


ID 


Optional . 

Die ID SOLL immer vorhanden 
sein, wenn ein Absender eine 
zuvor versendete MM andern 
will. Bezeichnet die 
Nachrichten-ID der MM, die der 
Absender andern will. 


X-Jmns- Status 


Andern 
erfolgreich 


Optional 

Zeigt an, ob eine Nachricht 

ersetzt wurde . 


X-Mcns-Date- 
Of -Execution 


Datum 


Optional . 

Zeigt das Datum an, an dem ein 
Rtickruf Oder eine Anderung 
ausgefuhrt wurde. 


X-Mms- 
Class 


Privat 1 
ruizexye 1 
Information | 
Auto 


Optional . 

Wenn das Feld nicht vorhanden 
ist, interpretiert der 
Empfanger die Nachricht als 
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privat . 


X-Mms- 
Priority 


Niedrig | Normal 
1 Hoch 


Optional. Voreinstellung: 
Normal 


X-Mms- 
De livery- 
Report 


Ja 1 Nein 


Optional . Voreinstellung: 
Nein. Spezif iziert , ob der 
Nutzer einen 

Auslief erungsbericht von jedem 
Empfanger in Form einer neuen 
Nachricht wunscht. 


X-Mms -Read- 
Reply 


Ja 1 Nein 


Optional . Voreinstellung : 
Nein. Spezif iziert, ob der 
Nutzer einen Lesebericht von 
jedem Empfanger in Form einer 
neuen Nachricht wfincmhi- 


Content-Type 


Inhaltstyp- 
Identif izierer 


Zwingend. Der Inhaltstyp der 
Nachricht. 
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Tabelle 7 



WAP Nachricht M- Acknowledge. ind (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Inhalt 


Koztinientare 


X-Mms- 

Message-Type 


m- acknowl edge- 
ind 


Zwingend, Identif iziert den 
Trans aktionstyp • 


X-Mms- 

Transact ion- 
ID 


Ein 

eindeutiger 
Ident i f i z i erer 


Optional. Dies ist die 
Transaktionsniunmer , die von 
der unmittelbar vorherigen M- 
Retrieve Operation starmnt. 
Wenn die M-Retrieve Operation 
keine Trans akti onsnummer 
enthielt, wird die 
Transaktionsnummer vom M- 
Acknowledge ebenso 
fortgelassen. 


X-Mms-MMS- 
Version 


Vers i onsnummer 


Zwingend . 

Die MMS Versionnummer . GemSS 
dieser Specification ist die 
Version 1.0. 


X-Mms- Status 


Riickruf 
erfolgreich | 
Rtickruf 
erfolglos | 
Andern 

erfolgreich | 

Andern 

erfolglos 


Optional , 


X-Mms -Report ~ 
Allowed 


Ja/Nein 


Optional. Voreinstellung : Ja. 
Senden von 

Auslieferungsbericht an den 
Nutzer erlaubt . 
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Tabelle 8 



WAP Nachricht M-Delivery.ind (dick eingerahmt: neu nach dieser Erfindung) 



Name 


Inhalt 


Konmientare 


X-Mms- 

Mes sage -Type 


m- deli very- ind 


Zwingend. Identif iziert den 
PDU-Typ 


X-Mms- 
Message-ID 




Zwingend. Von Send request; 
verbindet den 

Auslieferungsbericht mit der 
gesendeten Nachricht in MS. 


X-Mins-MMS- 
Version 


Ver s i onsnummer 


Zwingend. 

Die MMS Vers i onsnummer . GemaS 
dieser Spezif ikation ist dies 
die Version 1.0. 


To 


Empf angeradresse 


Zwingend. Wird gebraucht ziuti 
Berichten im Falle einer 
„point- to-multipoint 
Nachricht . 


Date 


Ereignisdatum 


Zwingend. Zeitpunkt, zu dem 
die Nachricht vom Empfanger 
Oder dem MMS -Server 
bearbe i t e t ( abgeho 1 1 , 
abgelaufen, . . . ) wurde. 


X-Mms-Status 


Rtickruf 
erfolgreich | 
Riickruf 
erfolglos | 
Andern 

erfolgreich | 
Andern erfolglos 


Zwingend. Status der 
Nachricht . 



Patentanspriiche 

1 . Verfahren zum Zugreifen auf eine erste Nachricht (MMa), insbesondere eine multimediale Nachricht (Multime- 
dia Message, MM) vorzugsweise vom MMS-Typ, wobei die erste Nachricht (MMa) niittels einer Sendeapplikation 
(MMS User Agent A) einer Sendeeinheit an eine Empfangsapplikation (MMS User Agent B) einer Empfangsein- 
heit gesendet wird, dadurch gekennzeiclinet, daB eine zweite Nachricht (MM^) mit einem Manipulationsauftrag 
zur Manipulation der ersten Nachricht (MMa) erstellt, versendet, empfangen, weitergeleitet und/oder verarbeitet 
wird, um einen manipulierenden Zugriff auf die erste Nachricht (MMa) zu veranlassen oder zu vermitteln. 

2. Verfahren nach Anspmch 1, dadurch gekennzeichnet, daB die erste Nachricht (MMa) i^nd die zweite Nachricht 
(MMb) uber Funk, iiber Mobilfunksysteme, zwischen Mobilfunksystemen, insbesondere Inter-Operator-IP-back- 
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bone, zwischen Mobilfunknetzen und anderen Nachrichten-Netzen, insbesondere Internet-Email, und/oder iiber das 
Internet versendet werden. 

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daB die erste Nachricht (MMa) und die 
zweite Nachricht (MM^) iiber mindestens ein senderseitiges Netzwerkelement (MMS Relay A) eines Service Pro- 
viders (Service Provider A) und mindestens ein empfangerseitiges Netzwerkelement (MMS Relay A; MMS Relay 5 
B) eines Service Providers (Service Provider A; Service Provider B) an die Empfangsapplikation (MMS User Agent 

B) gesendet wind. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daJ3 das mindestens eine senderseitige Netzwerkelement 
(MMS Relay A) und das mindestens eine empfangerseitige Netzwerkelement (MMS Relay B) dem Zustandigkeits- 
bereich (MMSEa) eines einzigen Service Providers (Service Provider A) angehoren oder sogar identisch sind. 10 

5. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Sendeapplikation 
(MMS User Agent A) und die Empfangsapplikation (MMS User Agent B) identisch sind. 

6. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der manipulierende ZugrifF 
auf die erste Nachricht (MM^) auf einem senderseitigen Netzwerkelement (MMS Relay A), auf einem empfanger- 
seitigen Netzwerkelement (MMS Relay B) und/oder auf der Empfangsapplikation (MMS User Agent B) erfolgt. 15 

7. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Manipulationsauftrag 

den Rijckruf bzw. das Loschen der ersten Nachricht (MM^) umfaBt, 

8. Verfahren nach einem der Anspriiche 1 bis 6, dadurch gekennzeichnet, daB der Manipulationsauftrag das Andem 
der ersten Nachricht (MMa) umfaBt, vorzugsweise durch Ersetzen der ersten Nachricht (MMa) durch die zweite 
Nachricht (MMb). 20 

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daB die zweite Nachricht (MM^) im Falle eines Ande- 
rungs-Auftrages entweder im PUSH-Modus (Driick-ZBring-Modus) oder im PULL-Modus (Zieh-/Hol-Modus) her- 
untergeladen v^rd. 

10. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die zweite Nachricht 

(MM^) mit dem Manipulationsauftrag an den Empfanger der ersten Nachricht (MM^) verschickt wird, wobei zur 25 
Kennung bzw. Identifizierung der ersten Nachricht (MM^) vorzugsweise deren Identifikationsnummer (IDl) ver- 
wendet wird, welche die erste Nachricht (MMa) zwischen der Sendeapplikation (MMS User Agent A) und einem 
senderseitigen Netzwerkelement (MMS Relay A) eindeutig kennzeichnet. 

11. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB beim Versenden einer 
Nachricht einem senderseitigen Netzwerkelement (MMS Relay A) von der Sendeapplikation (MMS User Agent A) 30 
eine oder mehrere der tblgenden Informationen bereitgestellt werden: 

Xennzeichnung, daB es sich bei der Nachricht (MM^) um einen Manipulationsauftrag handelt; 
Identifikationsnummer der ersten Nachricht (MMa), die manipuliert werden soli; 

Information, daB der Ab sender eine Ruckmeldung uber den Ausgang der von ihm initiierten Manipulation anfor- 
dert. 35 

12. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Sendeapplikation 
(MMS User Agent A) von einem senderseitigen Netzwerkelement (MMS Relay A) die Information bereitgestellt 
wird, ob dieses Netzwerkelement (MMS Relay A) die Manipulation gemaB den vorhergehenden Anspriichen unter- 
stutzt und/oder ob dar Manipulations- Auftrag der Sendeapplikation (MMS User Agent A) von dem Service Provi- 
der (Service Provider A) der Sendeapplikation (MMS User Agent A) angenommen wurde. 40 

1 3 . Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB bei Zugehorigkeit der Sen- 
deapplikation (MMS User Agent A) und der Empfangsapplikation (MMS User Agent B) zu unterschiedlichen Zu- 
standigkeitsbereichen (MMSEa, MMSEb) von Service Providem (Service Provider A, Service Provider B) einem 
empf anger seiti gen Netzwerkelement (MMS Relay B) von einem senderseitigen Netzwerkelement (MMS Relay A) 
eine oder mehrere der folgenden Informationen bereitgestellt werden: 45 
Kennzeichnung, daB es sich bei der zweiten Nachricht (MM^) um einen Manipulationsauftrag handelt; 
Identifikationsnummer der ersten Nachricht (MMa), die manipuliert werden soil; 

Information, daB der Ab sender eine Riickmeldung iiber den Ausgang der von ihm initiierten Manipulation anfor- 
dert. 

14. Verfahren nach einem der vorhergehenden Anspriichen, dadurch gekennzeichnet, daB Netzwerkelemente 50 
(MMS Relay A, MMS Relay B) von verschiedenen Service Providem (Service Provider A, Service Provider B) 
eine eineindeutige, umkehrbare Umwandlung von auf die erste und/oder die zweite Nachricht bezogene Identifika- 
tionsnummem (EDI, ID3; ID4, ID6, JD5) vomehmen und die entsprechenden Informationen vorzugsweise verwal- 
ten. 

15. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB im Falle eines Manipula- 55 
tionsauftrags, insbesondere einschlieBlich eines Loschungsbefehls, bei noch nicht erfolgter Benachrichtigung der 
EmpfangsappHkation (MMS User Agent B) iiber die erste Nachricht (MMa) diese erste Nachricht (MMa) im Zu- 
standigkeitsbereich (MMSEa) des senderseitigen Service Providers (Service Provider A) oder im Zustandigkeits- 

bereich (MMSE^) des empfangerseitigen Service Providers (Service Provider B) manipuliert, insbesondere ge- 
loscht, wird, wobei bevorzugt die Empfangsapplikation (MMS User Agent B) iiber die Manipulation nicht infor- 60 
miert wird. 

16. Verfahren nach einem der Anspriiche 1 bis 14, dadurch gekennzeichnet, daB im Falle eines Manipulationsauf- 
trags bei auf der Empfangsseite erfolgter Benachrichtigung, aber noch nicht heruntergeladener erster Nachricht 
(MMa) diese erste Nachricht (MMa) Zustandigkeitsbereich (MMSE^) des empfangsseitigen Service Providers 
(Service Provider B) manipufiert wird, wobei die Empfangsappfikation (MMS User Agent B) uber die Manipula- 65 
tion und iiber deren Zeitpunkt vorzugsweise informiert wird. 

17. Verfahren nach einem der Anspriiche 1 bis 14, dadurch gekennzeichnet, daB im Falle eines Manipulationsauf- 
trags bei auf der Empfangsseite erfolgter Benachrichtigung, aber noch nicht heruntergeladener erster Nachricht 
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(MMa) diese erste Nachricht (MMa) im Zustandigkeitsbereich (MMSEa) des senderseitigen Service Providers 
(Service Provider A) manipuliert wird, wobei die Empfangsapplikation (MMS User Agent B) iiber die Manipula- 
tion vorzugsweise nicht informiert wird. 

18. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Empfangsapplikation 
5 (MMS User Agent B) von einem empfangerseitigen Netzwerkelement (MMS Relay B) eine oder ggf. mehrere der 

folgenden Informationen, vorzugsweise in einer Benachrichtigung, bereitgestellt werden: 

Information, daB eine lediglich angekiindigte, aber noch nicht ausgelieferte erste Nachricht (MMa) nicht mehr zum 
Herunterladen bereitliegt, oder durch eine neue Nachricht (MMb) geandert worden ist, wobei die Identifizierung der 
ersten und/oder der zweiten Nachricht (MMa, MMb) vorzugsweise anhand des URI (Uniform Resource Identifier, 

10 d. h. einem Speicherplatz) erfolgt; 

Information, daB eine schon ausgelieferte erste Nachricht (MMa) vom Absender manipuliert werden mochte, wobei 
die Identifizierung der ersten Nachricht (MMa) auf der Empfangsapplikation (MMS User Agent B) vorzugsweise 
anhand einer Nachrichtenreferenz erfolgt, welche vorzugsweise ein URI ist, unter desssen Speicherplatz eine Stan- 
dard-Text-Nachricht des empfangerseitigen Service Providers (Service Provider B) abgespeichert ist, wobei die 

15 URI bevorzugt aus der Identifikationsnummer (EDI) der ersten Nachricht (MMa) oder von einem empfangerseiti- 

gen Netzwerkelement (MMS Relay B) festgelegten zweiten Identifikationsnummer (ID2) zusammengesetzt ist; 
Kennzeichnung, daB die zweite Nachricht (MMg) einen Manipulationsauftrag enthalt, der auf der Empfangsappli- 
kation (MMS User Agent B) ausgefiihrt werden soil; 

Information, welche bereits ausgelieferte Nachricht (MMa) manipuliert w^erden soli; 
20 Information, wann die Manipulation ausgefiihrt wurde; 

Information, daB die ausgelieferte zweite Nachricht (MM^) eine nachtraglich geanderte Nachricht ist; 
Information, welcher Art die vorzunehmende Manipulation ist. 

19. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB einem empfangerseitigen 
Netzwerkelement (MMS Relay B) von der Empfangsapplikation (MMS User Agent B) nach ihrer Benachrichti- 

25 gung fiber die zweite Nachricht (MMg) mindestens eine der folgenden Informationen bereitgestellt werden: 

Information, ob die Empfangsapplikation (MMS User Agent B) verstanden hat, daB die zuvor lediglich angekiin- 
digte erste Nachricht (MMa) erfolgreich manipuliert wurde; 

Information, ob die Manipulation der bereits heruntergeladenen ersten Nachricht (MMa) erfolgreich ausgefiihrt 
werden konnte; 

30 Information, ob der Empfanger dariiber informiert wurde und/oder zugestimmt hat, daB die bereits heruntergela- 

dene Nachricht (MMa) manipuliert wurde; 

Information, ob im Falle eines Anderungs-Auftrags die Anderung der bereits heruntetgeladenen ersten Nachricht 
(MMa) automatisch (PUSH-Modus) oder auf Veranlassung des Empfangers (PULL-Modus) durchgefiihrt wurde; 
Information, welcher Art die vorzunehmende Manipulation ist. 

35 20. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB bei Zugehorigkeit der Sen- 

deapplikation (MMS User Agent A) und der Empfangsapplikation (IVIMS User Agent B) zu unterschiedlichen Zu- 
standigkeitsbereichen (MMSEa, MMSE]^) von Service Providem (Service Provider A, Service Provider B) einem 
senderseitigen Netzwerkelement (MMS Relay A) von einem empfangerseitigen Netzwerkelement (MMS Relay B) 
eine oder mehrere der folgenden Informationen bereitgestellt werden: 

40 Information, ob der Manipulationsauftrag erfolgreich ausgefiihrt werden konnte; 

Information, wann der Manipulationsauftrag ausgefiihrt wurde; 
Information, ob der Manipulationsauftrag automatisch ausgefiihrt wurde; 

Information, ob der Empfanger fiber die Manipulation informiert wurde und/oder der Manipulation zugestimmt hat 
und/oder die Manipulation vom Empfanger veranlaBt wurde; 
45 Information, daB die bereits heruntergeladene erste Nachricht (MMa) manipuliert wurde, oder die erste Nachricht 

(MMa) vor einer Anderung noch nicht heruntergeladen war; 

Interims-Identifikationsnummer (103) der Nachricht (MMa), die manipuliert wurde; 
Information, welcher Art die vorgenonomene Manipulation ist. 

21. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB der Sendeapplikation 
50 (MMS User Agent A) von einem senderseitigen Netzwerkelement (MMS Relay A) eine oder mehrere der folgenden 

Informationen bereitgestellt werden: 

Information, ob der Manipulationsauftrag erfolgreich ausgefiihrt wurde; 
Information, wann der Manipulationsauftrag ausgefiihrt wurde; 
Information, ob der Manipulationsauftrag automatisch durchgeffihrt wurde; 
55 Information, ob der Empfanger iiber die Manipulation informiert wurde und/oder oder der Manipulation zuge- 

stimmt hat und/oder der Empfanger diese initiiert hat; 

Information, daB die bereits heruntergeladene Nachricht (MMa) manipuliert wurde, oder die erste Nachricht 
(MMa) vor einer Anderung noch nicht ausgeliefert war; 
Identifikationsnummer (EDI) der Nachricht (MMa), die manipuliert wurde. 
60 22. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB das Versenden, Empfan- 

gen und Manipulieren der Nachrichten (MM) mittels WAP-Nachrichten (Wireless Application Protocol) erfolgt. 

23. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die Manipulationsauftrage 
durch Modifizieren von vorhandenen Kopffeldern (Header- Feldem) und/oder durch Hinzuffigen von zusatzlichen 
Kopffeldern in geeigneten WAP-Nachrichten (WAP messages), insbesondere solche nach dem WAP-MMSEncap- 

65 sulation Standard und insbesondere die WAP-Nachrichten M-Send.req, M-Send.conf, M-Notification.ind, M-Noti- 

fyResp.req, M-Retrieve.conf, M-Acknowledge.ind, M-Delivery.ind, implementiert werden. 

24. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, daB die erste Nachricht 
(MMa) fiir eine Riickmeldung iiber das Ergebnis des Manipulationsauftrags anhand der Identifikationsnummer 
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(ID4) der zweiten Nachricht, (MMi^) sowie der Transaktions-Identifikationsnummem der entsprechenden WAP- 
Nachrichten, oder anhand eines zusatzlichen Kopifeldes (Header-Feldes), wobei Feld-Werte des neuen Kopffeldes 
die Identifikationsnummer (IDl) der ersten Nachricht (MMa) enth alien, identifiziert wird. 

25. Sende- und/oder Empfangseinheit, insbesondere zur zumindest teilweisen Durchfiihrung des Verfahrens nach 
einem der vorhergehenden Anspriiche, mit Mitteln zum Erstellen, Versenden, Empfangen und/oder Verarbeiten ei- 5 
ner ersten Nachricht (MMa), insbesondere einer multimedialen Nachricht (Multimedia Message) vorzugsweise 
vom MMS-Typ, gekennzeichnet durch Mittel zum Erstellen, Versenden, Empfangen und/oder Verarbeiten einer 
zweiten Nachricht (MMb), wobei die zweite Nachricht (MMb) einen Manipulationsauftrag zum Manipulieren der 
zuvor gesendeten ersten Nachricht (MMa) umfaBt. 

26. Sende- und/oder Empfangseinheit nach Anspruch 25, gekennzeichnet durch Mittel zum Ausfiihren des Mani- 10 
pulationsauf trag s . 

27. Sende- und/oder Empfangseinheit nach Anspruch 25 oder 26, dadurch gekennzeichnet, daB die Mittel zum Er- 
stellen, Versenden, Empfangen und/oder Verarbeiten der zweiten Nachricht (MM^) WAP-Nachrichten, insbeson- 
dere solche nach dem WAP-MMSEncapsulation Standard und insbesondere die WAP-Nachrichten M-Send.req, M- 
Send.conf, M-Notification.ind, M-NotifyResp.req, M-Retrieve.conf, M-Acknowledge.ind und M-Delivery.ind mit 15 
entsprechend den im Rahmen der Manipulations auftrage auszutauschenden Informationen modifizierten Kopffel- 
dern (Header-Feldem) und/oder zusatzlichen Kopffeldem umfassen. 

28. Kommunikationssystem, insbesondere Funkkommunikationssystem, insbesondere zur zumindest teilweisen 
Durchfuhrung des Verfahrens nach einem der Anspriiche 1 bis 24, mit mit Sende- und/oder Empfangseinheiten, ins- 
besondere solchen nach einem der Anspriiche 25 bis 27, kommunizierfahigen Netzwerkelementen (MMS Relay A; 20 
MMS Relay B), welche Mittel zum Empfangen und Weiterleiten von Nachrichten, insbesondere multimedialen 
Nachrichten (Multimedia Messages) vorzugsweise vom MMS-iyp, umfassen, dadurch gekennzeichnet, daB minde- 
stens eines der Netzwerkelemente (MMS Relay A; MMS Relay B) Mittel zum Empfangen, Verarbeiten und/oder 
Weiterleiten einer zweiten Nachricht (MM^) mit einem Manipulationsauftrag umfaBt, welcher sich auf eine emp- 
fangene und ggf. schon weitergeleitete erste Nachricht (MMa) bezieht, um einen manipulierenden Zugrifif auf die 25 
erste Nachricht (MMa) zu veranlassen oder zu vermitteln. 

29. Kommunikationssystem nach Anspruch 28, gekennzeichnet durch Mittel zum Ausfiihren des Manipulations- 

auftrags. 

30. Kommunikationssystem nach Anspruch 29, dadurch gekennzeichnet, daB die erste Nachricht (MMa) auf einem 
Netzwerkelement (MMS Relay A; MMS Relay B) und/oder auf einer Empfangsaplikation (MMS User Agent B) ei- 30 
ner Empfangseinheit manipulierbar ist, insbesondere loschbar und/oder anderbar. 

31. Kommunikationssystem nach einem der Anspriiche 28 bis 30, dadurch gekennzeichnet, daB die Mittel zum 
Empfangen, Verarbeiten und/oder Weiterleiten der zweiten Nachricht (MM^) WAP-Nachrichten, insbesondere sol- 
che nach dem WAP-MMSEncapsulation Standard und insbesondere die WAP-Nachrichten M-Send.req, M- 
Send.conf, M-Notification.ind, M-NotifyResp.req, M-Retrieve.conf, M-Acknowledge.ind und M-Delivery.ind mit 35 
entsprechend den im Rahmen der Manipulations auftrage auszutauschenden Informationen modifizierten Kopffel- 
dern (Header-Feldem) und/oder zusatzlichen Kopffeldem umfassen. 
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X^MmS'Repall'ID: (0x7F) 

Recall -ID- Value = Text -String 

X-Mms-RecallBd'URXi ( 0x80 ) 

Recalled-URI -Value = Text-String 



X-Mns-l^eplace- JD: ( 0x81 ) 

Replace- ID-Value = Text-String 

X'Mms'Replaced'Xmii ( 0x82 ) 

Replaced-URI -Value = Text-String 

X-Mms- Support Bd'-FBature : ( 0x83 ) 

Supported-Feature-Value=Recall | Replace | no support 

(Riickruf / Andern / keine Unterstutzung) 
recall = <Octet 128> 
replace = <Octet 129> 
no support = <Octet 13 0> 



X-Mms-DatB-Of-ExBCutiom (0x84) 

Date-Of-Execution-Value = Long-integer 
In seconds from 1970-01-01, 00:00:00 GMT 
(In Sekunden von 1970-01-01, 00:00:00 GMT)) 



X-Mai8-RG(zu.est "Report t (0x85) 

Request-Report-Value = Yes | No (Ja / Nein) 
Yes = <Octet 128> 
No = <Octet 129> 
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X-Mm8-Statu84 ( 0x14 ) 

Status-Value = Expired | (Abgelaufen) 

Retrieved | (Heruntergeladen) 
Rejected | (Zuriickgewiesen) 
Deferred j (Verschoben) 

Recall successful | (Ruckruf erfolgreich) 
Recall failed | (Ruckruf f ehlgeschlagen) 
Replace successful (Andern erfolgreich) 
Replace failed | ( Andern f ehlgeschlagen) 
Recall feature supported | 

( Ruckruf -Merkmal unterstiitzt) 
Replace feature supported 

( Anderungs -Merkmal -Unter s tut zung ) 

Expired = <Octet 12 8> 

Retrieved = <Octet 129> 

Rejected = <Octet 130> 

Deferred = <Octet 131> 

Recall successful = <Octet 132> 

Recall failed = <Octet 133> 

Replace successful = <Octet 134> 

Replace failed = <Octet 135> 

Recall feature supported = <Octet 13 6> 

Replace feature supported = <Octetl37> 

Fig. 6 



X-mis -Original -Messagre-Sta t us : ( 0x8 6 ) 

Original-Message-Status-Value = 

Recall successful | (Ruckruf erfolgreich) 
Recall failed | (Ruckruf f ehlgeschlagen) 
Replace successful | (Andern erfolgreich) 
Replace failed] (Andern f ehlgeschlagen) 

Recall successful = <Octet 128> 

Recall failed = <Octet 129> 

Replace successful = <Octet 130> 

Replace failed = <Octet 13 1> 

Fig. 7 



X-Mias-Original-Messaffe-IDz (0x87 ) 

Original -Message-ID-Value = Text-String 



Fig. 8 
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